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A translator system for translating source programs into 
machine language programs in an electronic computer sys- 
tem. An object program common to a plurality of different 
machine types of computers are generated while implement- 
ing execution performance equivalent to object programs 
inherent to the computers. A compiler translates a source 
program into an abstract object program including an 
abstract machine instruction sequence and indication con- 
cerning allocation of abstract registers. An installer converts 
the abstract object program into a machine language pro- 
gram of target computer on the basis of executable computer 
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FIG. 14 

Slnf (global, var, -^-3700 
((x, 1, int, 4), 
(a, 2, int 40, array, 10), 
<b, 2, int, 40, array, 10), 
(c, 2, int, 40, array, 10))) ; 
Slnf (local, func, var, ^-3702 
(0, 4, int, 4), (n, 4, int, 4))) ; 

alloc (Vbase,RcSect,AlcVb,0,0,Ox62489700 — 3710 

+0x00224897) : 

bblock (1, pred ( ), succ (2)) ; ^ 37*1 2 

Stmt Contl Noreg Noreg OdCi 10 ; 

Loops Contl Noreg Noreg OdLab LI ; 371 6 

alloc (Ar5,RcArith,Alc5,0,0,0xD1 044000 ^ 371 8 

+0x00110440) ; 

* Load RegCon Ar5 Noreg OdCi 0 ; ^-3720 

* Store Reg Mr Ar5 Vbase OdDisp i ; ^3722 

bblock (2, pred (1,8), succ (3,7)) ; ^3724 
Block ContO Noreg Noreg OdNo Null ; 

Lable Contl Noreg Noreg OdLab L1 ; -0728 
Stmt Contl Noreg Noreg OdCi 11 ; 

alloc (Ar6,RcAddr,Alc6,2,0,0xEOO0O000) ; -^-3732 

* Load RegReg Ar6 Vbase OdNo Null : ^-3734 

* Add RegReg Ar6 Ar5 OdNo Null ; -^3736 

alloc (Ar7,RcArith,Alc7,4,0,0xC0O0OOOO) ; 

* Load RegMr Ar7 Ar6 OdDisp a ; -^-3740 

free (Ar6) ; 

* Comp RegCon Ar7 Noreg OdCi 0 ; 

free (Ar7) ; 

BrLe Const Noreg Noreg OdLab L2 ; ^3748 
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FIG. 15 
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free (Arl 2) I 
free (Ar1 1 ) ; 
End ContO Noreg Noreg OdNo Null ; 
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FIG. 16 



D 




L4; 


-^3802 


L3 ; 


— 3806 


L5 : 


— 3808 


L4 ; 


-3812 


L5 ; 


— 3814 


12 ; 




14; 





Jump Const Noreg Noreg OdLab 

bblock(5, pred(3), succ(8)) ; 
Label Contl Noreg Noreg OdLab 
Jump Const Noreg Noreg OdLab 

bblock(6, pred(4, succ(8)) ; 
Label Contl Noreg Noreg OdLab 
Jump Const Noreg Noreg OdLab 

bblock(7, pred(2), succ (8)) ; 
Label Contl Noreg Noreg OdLab 
Stmt Contl Noreg Noreg OdCi 

alloc(Ar13, RcArith, Aid 3.1 5,0,0x90000000) ; 

* Load RegCon Ar13 Noreg OdCi 1 I /* Same as Aril */ 

alloc(Arl4, RcAddr, Alx14,16,O,OxEOO00O0O) \ ^3828 

* Load RegReg Ar14 Vbase OdNo Null ; 

* Add RegReg Ar14 Ar5 OdNo Null ; /* Same as Ar6 *A-2830 

* Store RegMr AR13 AM 4 OdDISP c .' 

free (Ar13) ; 

free(Ar14) ; 
End ContO Noreg Noreg OdNo Null ; 

bblock (8, pred (5,6,7), succ (2,9)) ; —3840 
Label Contl Noreg Noreg OdLab L5 ; 

alloc(Ar15, RcArith, Alc15,19,O,OxEO0O00O0) ; 

* Load RegMr Ar15 Vbase OdDisp j ; /* Same as Ar5*/^3846 

* Add RegCon Ar15 Noreg OdCi 1 ; 

* Store RegMr Ar15 Vbase OdDisp i ; —3850 

free(Ar15) ; 

alloc (Ar16,RcArith,Alc16,22,O,0xA0OO0O00) ; 

* Load RegMr Ar16 Vbase OdDidp i ; /* Same as Ar15 */J" 3856 

alloc (Ar17,RcArrth,Alc17,23,O,0xC00OOOO0) ; 

* Load RegMr Ar17 Vbase OdDisp n ; —3860 

* Comp RegReg Arl6 Ar17 OdNo Null ; 

free (Ar16) ; 
free (Ar17) ; 

BrLe Const Noreg Noreg OdLab LI ; ->-3868 
free (Ar5) ; 

bblock (9, pred (8), succ (10)) I 
Loope Contl Noreg Noreg OdLab LI ; -^-3874 
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FIG. 19 
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FIG. 20 



Slnf (global, var, 

((x, 1, int, 4), 
(a, 2, int, 40, array, 10), 
(b, 2, int, 40, array, 10), 
(c, 2, int. 40, array, 10))) ; 
Slnf (local, func, var, 

(0, 4, int, 4), (n, 4, int, 4))) ; 

alloc (Vbase,RcSect,AlcVb,0,0,Ox5C040000 

4-0x00404000) ; 

bblock (1, pred ( ), succ (2)) ; Vbase 
Stmt Contl Nor eg Noreg OdCi 10 ; I 
Loops Contl Noreg Noreg OdLab L1 ; I 

alloc (Ar5,RcArith,Alc5,0,O,OxC20EO000+0x0020E00O) ; — 4028 

* Load RegCon Ar5 Noreg OdCi 0 ; 15 -—4030 

* Store RegMr Ar5 Vbase OdDisp i ; Vb I -^4032 

alloc (Ar11,RcArrth,Alc1 1,2,4,0x80800000+0x00080000) I 
if (Alcll) { | | 

* Load RegCon Aril Noreg OcCi 1 ; } I I 11 -^4038 

alloc (Ar10,RcArith,Alc1 0,3,3,0x82000000+0x00200000) ; 
if (AlcIO) | III 

* Load RegMr ArlO Vbase OdDisp x ; | Vb I I 10 -^4044 

alloc (Ar17,RcArith,Alc1 7,4,2,0x80200000+0x00020000) ; -^-4046 
'f (Alcl7) { l l l I ^,4048 

* Load RegMr AM 7 Vbase OdDisp n; | Vb I I | 17-, . _ 

L 4050 
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FIG. 21 



bblock(2, pred(1,8), succ(3,7)) I 
Label Contl Noreg Noreg OdLab L1 
Stmt Contl Noreg Noreg OdCi 11 

alloc (Ar6, RcAddr,Alc10,5,0,OxE6000000) I 

* Load RegReg Ar6 Vbase OdNo Null ; Vb 

* Add RegReg Ar6 Ar5 OdNo Null 

alloc (Ar7, RcArith,Alc7,7,0,0xE000O0OO) 

* Load RegMr Ar7 Ar6 OdDisp a ; 

* Comp RegCon Ar7 Noreg OdCi 0 ; 
BrLe Const Noreg Noreg OdLab L2 ; 

bblock (3. pred(2), succ(8)) ; 
Stmt Contl Noreg Noreg OdCi 12 ; 

* Comp RegReg Ar7 ArlO OdNo Null I 

free (Ar7) ; 

if OAldO) free (ArlO) I 
BrGe Const Noreg Noreg OdLab L5 ; 

bblock (4, pred(3), succ(4,8)) ; 
Stmt Contl Noreg Noreg OdNo Null ; 

* Store RegMr AM 1 Ar6 OdDisp b ; 
Jump Const Noreg Noreg OdLab L5 ; I 

bblock(7, pred(2), succ(8)) ; 
Label Contl Noreg Noreg OdLab L2 ; 
Stmt Contl Noreg Noreg OdCi 14 ; 

* Store RegMr Ar11 Ar6 OdDisp c ; 

free (6) ; 

if OAlcll) free (Aril) ; 
bblock (8, pred (3,4,7), succ (2,9)) ; 
Label Contl Noreg Noreg OdLab L5 ; II 

* Add RegCon Ar5 Noreg OdCi 1 ; 15 

* Store RegMr Ar5 Vbase OdDisp i ; Vb 5 

* Comp RegReg Ar5 Ar17 OdNo Null ; I 5 17 

if OAlcll) free(Ar17) ; I I f 

BrLe Const Noreg Noreg OdLab L1 ; 

if (AlclD free(Arll); I | 

if (AldO) free (ArlO) ; 
if (Aid 7) free(Ar17); 
free(Ar5) ; 

bblock (9, pred (8), succ (10)) I 
Loope Contl Noreg Noreg OdLab L1 ; 
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; [ 0 . . 31] ; -—4278 
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FIG. 25 
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(GENERATED PATTERN n| 
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FIG. 26 



Load RegCon Regl Noreg OdCi C —-4300 

lif ($C<65536) && ($C>=0) — 4302 

genC ori ', $Reg1, ' $0', $C, null, null) : — 4304 
else { 

genC iui\ $Regl, SC/65536, null, null, null) ; — 4308 

genC ori ',$Reg1, SRegl, $C %65536, null, null) ; I ;7 

) 4310 

I Load RegMr Regl Reg2 OdDisp V —4312 
IgenClw', $Reg1, $V, ' ( , ,$Reg2, ')'); 

) 

I Load RegReg Regl Reg2 OdNo Null -^-4316 
Add RegReg Regl Reg3 OdNo Null 
foenCadd '. $Reg3, $Reg2, $Reg1, null, null) ; 

I Store RegMr Regl Reg2 OdDisp V 

IgenCsw SRegl, $V, ' (', $Reg2, ')') ; 

I 

I Add RegCon Regl NoReg OdCi C 

{if ($C<32768) && ($C>= -32768) 

genCaddi ', SRegl. SRegl, SC. null, null) ; 
else I 

gen (' Iw *, ' $24', '=', $C, null, null) ; 
^ gen ('add', $Reg1, SRegl, '$24', null, null) ; | ; 

I Comp RegCon Regl Noreg OdCi 0 
BrLe Const Noreg Noreg OdLab L 
foenC blez SRegl, Label ($L), null, null, null) ; 

I Comp RegReg Real Reg3 OdNo Null 
BrGe Const Noreg Noreg OdLab L 
(gen (' sub ', SRegl, $Reg2, '$24*. null, null) ; 
^genC bgez',' $24', Label ($L), null, null, null) ; 

I Jump Const Noreg Noreg OdLab L 

IgenC j ', Label (&L), null, null, null, null) ; 
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FIG. 27 
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FIG. 3 1 
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FIG. 32 
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FIG. 33 



Load RegCon Regl Noreg OdCi C -^.4700 
(if ($C<4096) && ($C>=-4096) 

gen Cor', '%0\ $Reg1, null, null) ; 
else ( 

genC sethi SC/4096, $Regl, null, null, null) ; 
^ gen Cor ',$Reg1, $C % 4096, $Reg1, null, null) ;j ; 

I Load RegMr Regl Reg2 OdDisp V ^4712 
(genC Id', $Reg2, '+', $V, $Reg1, null) ; 

) 

I Load RegReg Regl Reg2 OdNo Null -^4716 
Add RegReg Regl Reg3 OdNo Null 
{gen ('add ', SReg2, $Reg3, $Reg1, null, null) ; 

I 

I Store RegMr Regl Reg2 OdDisp V -^4722 
(genCst '. SRegl, $Reg2, '+', $V, null) ; 

) 

I Add RegCon Regl NoReg OdCi C 

(if ($C<4096) && ($C>=-4096) 

gen ('add ', '%0', $C, SRegl, null, null) ; 
else ( 

genCid ', '=', $C, '%15',null, null); 
^ gen ('add', $Reg1, '%15\ SRegl, null, null) ; | ; 

I Comp RegCon Regl Noreg OdCi 0 
BrLe Const Noreg Noreg OdLab L 
(gen C sub ', $Reg1, '%0\ $Reg1, null, null) ; 
^genCble Label ($L), null, null, null, null) : 

I Comp RegReg Real Reg3 OdNo Null 
BrGe Const Noreg Noreg OdLab L 
(gen ('sub $Reg1, $Reg2, "%15\ null, null) I 

^genCbge ', Label ($L), null, null, null, null) ; 

I Jump Const Noreg Noreg OdLab L 

{gen (' ba ', Label (&L), null, null, null, null) ; 
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FIG. 34 
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RETARGETABLE INFORMATION PROCESSING 
SYSTEM 

BACKGROUND OF THE INVENTION 
[0001] The present invention relates to a translation sys- 
tem for translating a source program into a machine lan- 
guage program by using an electronic computer and more 
particularly to a translation system of the type mentioned 
above in which an object program common to a plurality of 
target computers or machines of different types can profit- 
ably be employed. 

[0002] Systems for allowing programs described in high- 
level languages to be executed on the target computers or 
machines are generally classified into two systems respec- 
tively referred to as a compiler system and an interpreter 
system. 

[0003] In the compiler system, a program described in a 
high-level language is translated into a machine language 
program oriented to a target computer, and the machine 
language program is executed straightforwardly by the tar- 
get machine. 

[0004] On the hand, in the case of the interpreter system, 
a language (referred to as the intermediate language) which 
differs from the machine language of the target computer is 
prepared along with a program (referred to as the interpreter) 
which is adapted to interpret and execute the intermediate 
language program on the target computer. In other words, 
the high-level language program is once translated into the 
intermediate language program which is then executed by 
the target computer or machine on which the interpreter 
program runs. 

[0005] One of advantages of the compiler system over the 
interpreter system is seen in a high-speediness of program 
execution which can be explained by the facts mentioned 
below. 

[0006] (1) In the interpreter system, there are required in 
addition to the execution of a machine language program 
corresponding to an intermediate language program, alloca- 
tion of the processings for the intermediate language codes 
as well as address calculation for operands and others. On 
the other hand, in the compiler system, such processing 
allocation and address calculation are rendered unnecessary 
because the machine language program can directly be 
executed in a straightforward manner 
[0007] (2) In the compiler system, sparing or deletion of 
some of the processings is possible by taking into consid- 
eration the context of program and characteristics of the 
target computer (i.e.. program optimalization can be real- 
vjzed). In contrast, the^ interpreter" can only execute the 
intermediate language program as it is because of its uni- 
versalness to the intermediate languages and thus the inter- 
preter is not in the position to allow any processing to be 
spared or omitted in consideration of the program context. 
Besides, since the characteristics of the target computer or 
machine are not reflected onto the intermediate language 
program, it is impossible to speed up the processing by 
resorting to, for example, mapping of specific variables 
described in a high-level language to the registers incorpo- 
rated in the target machine. 

[0008] On the other hand, as to the usage of a program 
destined to be executed repetitively, there has heretofore 
been adopted either one of the two methods mentioned 
below. 



[0009] (1) According to a first method, the compiler sys- 
tem is adopted, wherein the machine language program 
obtained through the translation is preserved or stored so as 
to be repetitively executed in a straightforward manner. 

[0010] (2) According to the other method, the interpreter 
system is adopted, wherein the intermediate language pro- 
gram is stored for allowing repetitive executions thereof by 
the interpreter. 

[0011] When one program is to be executed repetitionally, 
the compiler system is adopted by an overwhelming major- 
ity from the viewpoint of reduction of the time involved in 
execution of the program. However, the compiler system 
suffers from the undermentioned shortcomings. 

[0012] (1) It is necessary to provide the compiler for 
translating a source program into a machine language pro- 
gram for each type of the target machine, which means that 
not only a quantity of compilers to be developed will 
necessarily increase but also overhead involved in mainte- 
nance and extension is significantly increased because the 
maintenance and extension must be performed so as to be 
compatible with the machine types of the target computers. 

[0013] (2) In the case where one and the same program is 
to be executed by a plurality of target computers of different 
machine types, compilation (i.e. translation from a source 
program to a machine language program) is required for 
each of the machine types of the target computers, which 
results in that overhead in the management of the machine 
language programs increases remarkably. 

[0014] (3) In an environment in which a plurality of 
computers of different machine types are connected to a 
network, a number of machine language programs which 
correspond to the number of the computers connected to the 
network are required for one and the same source program, 
which gives rise to problems with regards to the version 
management and disk space availability. Moreover, diffi- 
culty will be encountered in distributed execution of one and 
the same program. 

[0015] (4) Some of the systems used actually is often 
operated with only the machine language program without 
any source program given. In such system, exchange or 
switching and alterations of the component machines is 
difficult to realize. At present, progress in the hardware 
technology facilitates implementation of highly sophisti- 
cated computer architecture. Nevertheless, inheritance of the 
machine language program resources imposes a serious 
limitation to alteration or modification of the computer 
architecture. 

[0016] For overcoming the disadvantages of the compiler 
system mentioned above, such a system may be conceived 
in which an intermediate language program which is inde- 
pendent of any specific machine is employed for the purpose 
of preservation or storage and management of the program, 
wherein upon execution, the intermediate language program 
is translated into a machine language program of a target 
machine for thereby realizing a high-speed processing, i.e. a 
system which adopts only the advantageous features of the 
compiler system and the interpreter system in combination. 
In the present state of the art, however, there is known no 
real system which incarnates the concept mentioned above. 

[0017] Parenthetically, for details of the compiler system 
and the interpreter system, reference may be made to "A 
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Aho, R. Seti and J. Ullman: Compilers. Principles, Tech- 
niques and Tools", Addison-Wesly, 1986, pp. 1-24. 

[0018] In order to allow a machine-independent interme- 
diate language program (i.e. intermediate language program 
which is independent of any specific target machine or 
computer) to be adopted as a form for preservation and 
management of a program to be executed repeatedly, it is 
required that the intermediate language program can be 
executed at a speed comparable to that of execution of the 
machine language program in the existing compiler system. 

[0019] To this end, fulfillment of the requirements men- 
tioned below will be indispensable. 

[0020] (1) The intermediate language program which is in 
the form suited for the preservation and management as 
described above is not executed by the interpreter but 
translated into a machine language program immediately 
before the execution. 

[0021] (2) In the course of the translation or conversion of 
the intermediate language program into the machine lan- 
guage program, optimalization of the program is carried out 
by taking into consideration the characteristics of the target 
computer which is to execute that program. 

[0022] With the present invention, it is contemplated to 
provide a consolidated or integrated system which can 
realize the requirements mentioned above, i.e. to provide a 
practical form of an intermediate language for storage and 
management of the intermediate language program together 
with a practical method of effectuating the translation of the 
intermediate language program into the machine language 
program upon start of execution of the program while 
optimalizing the machine language program for the target 
computer. 

[0023] In this conjunction, it is noted that the intermediate 
language code designed for the interpreter system can not be 
used as the intermediate language codes for realizing what 
is contemplated with the present invention for the reasons 
described below. 

[0024] (1) The intermediate language code for the inter- 
preter system contains no information required for optimal- 
ization to be effectuated upon translation into the machine 
language program because the intermediate language codes 
are not designed on the premise that it undergoes the 
optimalization by the interpreter. 

[0025] (2) The computers may globally be classified into 
a register machine which includes a finite number of regis- 
ters and in which operations are performed primarily on the 
registers and (a stack machine which includes operation 
stacks, wherein the operations or computation is performed 
primarily on the stack. In the current state of the art, a 
majority of the existing computers are implemented as the 
register machines. By contrast, many of the intermediate 
languages for the interpreter systems are designed on the 
presumption of operation on the stack because of the ease in 
designing the intermediate language codes and the inter- 
preter. Of course, it is not absolutely impossible to convert 
the on-stack operation to the operation on the registers. 
However, a great difficulty will be encountered in translating 
the intermediate language program for the stack machine 
into an efficient and effective machine language program for 
the register machine, when considering the fact that the 



values on the stack are inherently assumed to be disposable, 
while those on the registers should rationally be used 
repetitively as far as it is possible in order to make the most 
of the registers with a high efficiency. 

SUMMARY OF THE INVENTION 

[0026] It is therefore an object of the present invention to 
provide information processing method and system in which 
an intermediate language program independent of any spe- 
cific computer or machine is used for storage, management 
and the like purpose and translated into a machine language 
program appropriate to a target machine immediately before 
execution of the program by the target machine. More 
specifically, it is contemplated with the present invention to 
provide an information processing system which can fulfill 
the requirements described below. 

[0027] (1) Putting preponderance on a register machine as 
the target machine (i.e. execution-destined computer), the 
intermediate language program be of such an instruction 
sequence in which existence of registers is presumed at the 
very level of intermediate language program. Besides, in the 
course of translation up to the intermediate language pro- 
gram, optimalization should have been effectuated to a 
possible extent. 

[0028] (2) Upon translation into the machine language 
program from the intermediate language program, a register 
utilization method should be able to be optimalized. More 
specifically, utilization of the registers should be so deter- 
mined that the number of times the instructions for loading 
and storing values to and from registers should be reduced 
to a minimum while allowing unnecessary instructions to be 
deleted. Moreover, information requisite for the optimaliza- 
tion should be derived from the intermediate language 
program. 

[0029] (3) In some case, a specific sequence (a series of 
plural instructions) in the intermediate language program 
can be replaced by an instruction peculiar to the target 
machine. In such case, it is preferred in general from the 
standpoint of efficiency to effectuate the replacement by one 
machine language instruction. Accordingly, when a machine 
language instruction corresponding to a succession of inter- 
mediate language instructions exists availably by the target 
machine, a machine language program should be generated 
such that the corresponding machine language instruction 
mentioned above can be made use of. 

[0030] Aspects of the present invention in general may be 
summarized as follows. 

[0031] 1. System Structure 

[0032] According to an aspect of the present invention, a 
system for translating a source program into a machine 
language program for an execution-destined computer or 
target machine is composed of three subsystems. They are: 

[0033] (1) a compiler: a subsystem for generating an 
object program (referred to as abstract object program) 
which is independent of the type of the target machine, 

[0034] (2) a linker: a subsystem for linking together a 
plurality of abstract object programs generated by the 
subsystem compiler into a single abstract object pro- 
gram, and 



04/16/2004, EAST Version: 1.4.1 



US 2002/0026633 Al 



3 



Feb. 28, 2002 



[0035] (3) an installer: a subsystem for translating the 
abstract object program outputted from the linker into 
a machine language program for the target machine 
(which may also be referred to as the target computer, 
execution-destined machine or the like). 

[0036] 2. Form of Object Program 

[0037] In order to make the object program common to a 
plurality of target machines, an abstract register machine 
(also referred to as ARM or Arm in abbreviation) having a 
plurality of registers is presumed, wherein an instruction 
sequence for the abstract register machine or ARM is made 
use of as a basic part of the common object program 
(referred to as the abstract object program). 

[0038] The abstract register machine or ARM has features 
mentioned below. 

[0039] (1) The ARM has a plurality of abstract registers. 
(Although the number of the abstract registers is infinite in 
principle, limitation is imposed in dependence on the form 
of the abstract object program in practical applications.) 

[0040] (2) The ARM has as the instruction executing 
functions a register-memory data transfer function, function 
for performing operations on the registers (such as four 
arithmetic operations, logical operations, shift operations, 
comparisons) and an execution control function (such as 
unconditional branch, conditional branch, call and restora- 
tion of subprograms, etc.). 

[0041] (3) Memory addresses are represented by symbol 
names rather than numerical values. 

[0042] The reason why the instruction sequence of the 
abstract register machine or ARM including a plurality of 
registers is made use of as the basic part of the common 
object can be explained as follows: 

[0043] (a) In order to speed up the translation of the 
object program into machine language programs appro- 
priate to the individual target machines, respectively, it 
is desirable to reduce as for as possible semantic gaps 
between the object program and the machine language. 
In this conjunction, it is to be noted that the computa- 
tion machine used widely at present is a register 
machine having a plurality of registers. Accordingly, by 
presuming the abstract register machine having as an 
instruction set a semantically common part of the 
instruction sets of the conventional register machines, 
overhead involved in the semantically meaningful 
translation can be reduced, whereby the translation to 
the machine language program can be speeded up. 

[0044] (b) In the register machine, one of the keys for 
speeding up execution of the machine language pro- 
gram is effective utilization of the registers. Thus, by 
regarding the abstract register machine or ARM as a 
target machine for the compiler, the latter can generate 
a instruction sequence which can make use of the 
registers to a maximum possible extent. 

[0045] The abstract object program is composed of: 

[0046] (a) instruction sequence forth ARM, 

[0047] (b) pseudo-codes such as definitions of labels 
concerning branch, entry, variable and constant, 



embedded information for the optimalization, and 
embedded information for the debugging at the source 
program level, 

[0048] (c) generation control specifiers (indicating allo- 
cation/deallocation of abstract registers and selection of 
an ARM instruction sequence in the state in which the 
abstract registers have been allocated), and 

[0049] (d) dictionaries of variable names and index 
names for reference in the debugging at the level of the 
source program, 

[0050] Although the type of the abstract register can be 
indicated by the generation control specifier for the abstract 
registers, it is impossible to designate to which of the 
registers in the real machine the indicated abstract register 
correspond. In this manner, the registers can be surfaced up 
in the abstract object program independent of the type of the 
target machine. 

[0051] 3. Specification of Target Machine 

[0052] In order to allow the machine language programs 
for the target machine to be generated from the abstract 
object program, tow types of information mentioned below 
are prepared for the installer: 

[0053] (i) indication concerning the usage of the register 
in the target machine (types and number of the usable 
registers), and 

[0054] (ii) translation rules for translation of the instruc- 
tion sequence pattern of the ARM into an instruction 
sequence pattern for the target machine. 

[0055] At this juncture, it should be mentioned that the 
ARM instruction pattern and that of the target machines are 
each composed of a plurality of instructions. 

[0056] The instructions of the ARM and those of the target 
machine are not set in one-to-one correspondence relation, 
the reason for which is explained as follows. 

[0057] (1) In a strict sense, the ARM instruction set can 
not constitute a common part of real machine instruction 
sets. Accordingly, there may arise such situation in which the 
instruction corresponding to that of the ARM is absent in the 
instructions executed by the a target machine. In that case, 
it is necessary to realize one ARM instruction by several 
instructions of the target machine. 

[0058] (2) There may arise a situation which is reverse to 
that mentioned above. In other wards, the instruction 
sequence executed by the target machine may include an 
instruction which corresponds to a sequence of several ARM 
instructions, as exemplified by a register-memory operation 
instruction and the like. In this case, the ARM instruction 
sequence is handled as one target machine instruction, 
because the processing speed can be enhanced by decreasing 
the number of the instructions to be executed by the target 
machine. 

[0059] 4. Method of translating the abstract object pro- 
gram into a machine language program for a target machine. 

[0060] The installer includes a table for managing corre- 
spondences between the abstract registers of the ARM and 
the real registers of the target machine (this table will 
hereinafter be referred to as the register management table) 
and performs operations mentioned below. 
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[0061] (1) In response to an abstract register allocation 
command for the abstract registers in the abstract object 
program, the installer attempts to establish correspondence 
between an abstract register and a real register. In that case, 
when there exists a real register for which correspondence 
with other abstract register has not been established within 
a range described in register usage indication of the target 
machine specifications, i.e. where there is found an idle real 
register, correspondence is established between the afore- 
mentioned abstract register and the idle real register. 

[0062] (2) In response to a register releasing or freeing 
command contained in the abstract object program, the 
installer clears the correspondence relation between the 
abstract register and the real register (i.e. deallocation is 
executed by the installer). 

[0063] (3) With the aid of the generation control specifier 
contained in the abstract object program, the installer checks 
whether or not an abstract register is set in correspondence 
relation with a real register, whereon an ARM instruction 
sequence is selected. 

[0064] (4) For the ARM instruction sequence thus 
selected, the installer applies translation rules contained in 
the target machine specifications for translating the ARM 
instruction sequence pattern into a target machine instruc- 
tion sequence pattern, to thereby generate a target machine 
instruction sequence corresponding to the selected ARM 
instruction sequence while replacing the abstract register 
identification number by that of the real register. 

[0065] (5) For the target machine instruction sequence 
thus generated, the installer converts the symbol name 
representing the memory address into numeric addresses. 

[0066] The compiler which may be implemented by 
applying compiler techniques known heretofore serves for 
translation of a source program into an abstract object 
program. Simultaneously, the compiler performs optimal- 
ization at the source program level as well as optimalization 
of the ARM instructions for which utilization of the registers 
is prerequisite. 

[0067] In this way, the installer generates a machine 
language program for a target machine from an abstract 
object program in conformance with the target machine 
specifications. 

[0068] Tims, the machine language program for the target 
machine as generated by the system according to the inven- 
tion has features mentioned below. 

[0069] (1) Optimalization at the source program level as 
well as optimalization of tbe register utilization is realized 
by the compiler. 

[0070] (2) Owing to the real register allocation function of 
the installer, the registers incorporated in the target machine 
can be made use of to a maximum extent. 

[0071] (3) Owing to the instruction sequence pattern 
replacing capability or function of the installer, it is possible 
to replace a succession of plural ARM instructions by one 
instruction for the target machine, to thereby make the most 
of a high performance of the target machine. As a result of 
this, an object program can be shared by a plurality of 
different machine type computers while maintaining the 
execution speed and performance which are equivalent to 



those involved in the execution of the machine language 
program generated by the prior art system (prior rt compiler 
system). 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0072] FIG. 1 is a diagram showing schematically a 
general arrangement of a translation system for translation 
of a source program into a machine language program 
according to an embodiment of the present invention; 

[0073] FIG. 2 is a diagram showing schematically a 
structure of a compiler for generating from a source program 
an abstract object program in the form of a sequence of 
abstract register machine instruction; 

[0074] FIG. 3 is a diagram showing a relation between an 
abstract register machine instruction sequence and a 
machine language instruction sequence for a particular 
machine; 

[0075] FIG. 4 is a view for illustrating types of generation 
control statements contained in an abstract register machine 
instruction; 

[0076] FIG. 5 is a view for illustrating a format of an 
abstract register machine instruction; 

[0077] FIG. 6 is a view for illustrating relations between 
address modes and operands in abstract register machine 
instructions; 

[0078] FIG. 7 is a first part of a view showing specifica- 
tions of a machine language generation instruction contained 
in the abstract register machine instruction; 

[0079] FIG. 8 is a second part of the view showing 
specifications of a machine language generation instruction 
contained in the abstract register machine instruction; 

[0080] FIG. 9 is a third part of the view showing speci- 
fications of a machine language generation instruction con- 
tained in the abstract register machine instruction; 

[0081] FIG. 10 is a fourth part of the view showing 
specifications of a machine language generation instruction 
contained in the abstract register machine instruction; 

[0082] FIG. 11 is a fifth part of the view showing speci- 
fications of a machine language generation instruction con- 
tained in the abstract register machine instruction; 

[0083] FIG. 12 is a sixth part of the view showing 
specifications of a machine language generation instruction 
contained in the abstract register machine instruction; 

[0084] FIG. 13 is a view for illustrating an example of the 
source program which is inputted to the compiler shown in 
FIG. 2; 

[0085] FIG. 14 is a first part of a view showing an 
example of the abstract object program corresponding to the 
source program shown in FIG. 13 in the state not optimal- 
ized yet; 

[0086] FIG. 15 is a second part of the view showing an 
example of the abstract object program corresponding to the 
source program shown in FIG. 13 in the state not optimal- 
ized yet; 
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[0087] FIG. 16 is a third part of the view showing an 
example of the abstract object program corresponding to the 
source program shown in FIG. 13 in the state not optimal- 
ized yet; 

[0088] FIG. 17 is a view for illustrating a process of 
calculating priorities of register allocations in the abstract 
object program shown in FIGS. 14 to 16; 

[0089] FIG. 18 is a flow chart for illustrating a procedure 
for generating priority bit vectors representing the priorities 
for the register allocation in the compiler shown in FIG. 2; 

[0090] FIG. 19 is a flow chart for illustrating a process of 
eliminating a common expression as executed as a part of 
optimization processing by the compiler shown in FIG. 2; 

[0091] FIG. 20 is a first part of a view showing an 
example of the abstract object program corresponding to the 
source program shown in FIG. 13 for illustrating an abstract 
register machine instruction sequence resulting from opti- 
malization processing; 

[0092] FIG. 21 is a second part of the view showing an 
example of the abstract object program corresponding to the 
source program shown in FIG. 13 for illustrating an abstract 
register machine instruction sequence resulting from opti- 
malization processing; 

[0093] FIG. 22 is a flow chart illustrating a processing for 
effectuating move of intra-loop invariants; 

[0094] FIG. 23 is a view showing usages of physical 
registers in a target machine A; 

[0095] FIG. 24 is a view for illustrating correspondence 
relations between the physical registers the abstract regis- 
ters; 

[0096] FIG. 25 is a flow chart for illustrating a translation 
into a machine language with the aid of pattern matching 
technique; 

[0097] FIG. 26 is a view showing a part of machine 
instruction selecting rules oriented for the target machine A; 

[0098] FIG. 27 is a view showing a state in which physical 
registers in the target machine A are allocated to the abstract 
object program shown in FIGS. 20 to 21; 

[0099] FIG. 28 is a view showing a machine language 
program which is generated from the abstract object pro- 
gram shown in FIGS. 20 and 21 by an installer for the target 
machine A; 

[0100] FIG. 29 is a flow chart for illustrating processings 
performed internally of the installer; 

[0101] FIG. 30 is a schematic block diagram showing a 
structure of the installer together with inputs and an output 
thereof; 

[0102] FIG. 31 is a view showing usages of the physical 
registers in a target machine B; 

[0103] FIG. 32 is a view showing a state in which the 
physical registers of the machine B are allocated to the 
abstract object program shown in FIGS. 20 and 21; 

[0104] FIG. 33 is a view showing a part of the machine 
instruction selecting rules oriented for the machine B; 



[0105] FIG. 34 is a view showing a state in which the 
physical registers of the machine B are allocated to the 
abstract object program shown in FIGS. 19 and 20; 

[0106] FIG. 35 is a view showing an example of machine 
language program generated by the installer for the machine 
B from the abstract object program shown in FIGS. 19 and 
20; 

[0107] FIG. 36 is a block diagram showing a structure of 
debug system to which the installer according to an embodi- 
ment of the invention is applied; 

[0108] FIG. 37 is a flow chart for illustrating operation of 
the debugger; 

[0109] FIG. 38 is a view showing an example of a display 
command; 

[0110] FIG. 39 is a flow chart for illustrating the display 
processing; 

[0111] FIG. 40 is a view showing an example of a 
break-point setting command; 

[0112] FIG. 41 is a flow chart for illustrating a break-point 
setting processing; 

[0113] FIG. 42 is a view showing an example of execution 
command; 

[0114] FIG. 43 is a flow chart for illustrating execution 
processing and shows details of the processing in a step 5128 
shown in FIG. 37; 

[0115] FIG. 44 is a view showing an example of the 
source program which is subject to the debugging; 

[0116] FIG. 45 is a view showing an example of a 
source/abstract object/machine language correspondence 
table; 

[0117] FIG. 46 is a block diagram showing a structure of 
an IC card device incorporating an installer according to the 
invention; 

[0118] FIG. 47 is a pictorial view showing an outer 
appearance of an IC card system; 

[0119] FIG. 48 is a top plan view of an IC card; 

[0120] FIG. 49 is a flow chart for illustrating execution of 
an abstract object program incorporated in the IC card; 

[0121] FIG. 50 is a block diagram showing a system in 
which one and the same abstract object program contained 
in an IC card is executed by a plurality of IC card systems 
having different CPUs, respectively; 

[0122] FIG. 51 is a block diagram showing a system in 
which abstract register machine code programs are shared 
by computer systems of different machine types which are 
linked together through a network; and 

[0123] FIG. 52 is a block diagram illustrating, by way of 
example, replacement of a computer system in which an 
abstract register machine program is employed by another 
type of computer system. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 
[0124] Now, the present invention will be described in 
detail in conjunction with exemplary or preferred embodi- 
ments by reference to the accompanying drawings. 
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[0125] FIG. 1 is a diagram showing an exemplary struc- 
ture of a translation system for translating a source program 
into a machine language program, according to an embodi- 
ment of the present invention. 

[0126] The translation system includes three subsystems. 
They are a compiler 1001, a linker 1002 and a installer 1003, 
respectively. 

[0127] When a source program 1004 is inputted to the 
compiler 1001, the compiler 1001 performs a syntax analy- 
sis, a semantic analysis, an optimalization processing 
(described hereinafter) and others on the source program 
1004, at the representation level of the source program, to 
thereby output an ArmCode (Abstract register machine 
code) program 1005 which is an abstract object program. At 
this juncture, it should be noted that the ArmCode program 
is provided according to one of the aspects of the present 
invention, and the specifications of the ArmCode program 
will hereinafter be elucidated in detail by reference to FIGS. 
4 to 12. As to the compiler 1001, a structure thereof will be 
described by referring to FIG. 2, while the optimalization 
processing performed by the compiler will be described later 
on in detail by reference to FIGS. 13 to 22. 

[0128] The linker 1002 receives the ArmCode program 
1005 generated from the source program 1004 by the 
compiler 1001, another ArmCode program 1007 generated 
similarly from another source program 1006 by the compiler 
1001 and an ArmCode program library 1008, and performs 
solution of problems concerning a relation between routines 
referenced to by the programs and a relation between 
variables or constants referenced to as well as integration of 
data areas and that of instruction areas, as a result of which 
a linked ArmCode program 1009 is outputted from the linker 
1002. Parenthetically, the function of the linker itself is 
equivalent to a part of the function of the object program 
linkage editor known heretofore if the ArmCode program is 
regarded as a conventional machine language. Accordingly, 
any further description of the linker 1002 will be unneces- 
sary. 

[0129] The installer 1003 is loaded with the linked Arm- 
Code program 1009 to perform a real register allocation, 
selection or generation of machine instructions and a 
machine-dependent optimalization with the aid of register 
usage designation 1019 and machine instruction generating 
rules 1020 which are contained in specifications information 

1010 of a target machine or computer A 1012 and then the 
installer 1003 develops a machine language program 1011 
on a memory of the target machine A 1012. The processings 
carried out by the installer also constitutes one of the aspects 
of the present invention and will be described in detail later 
on by reference to FIGS. 23 and 30. The computer or 
machine A 1012 executes the machine language program 

1011 developed in the manner as mentioned above. 

[0130] In case the ArmCode program 1014 generated from 
the source program 1013 by the compiler 1001 requires no 
linkage with anyone of ArmCode programs and the Arm- 
Code program library 1008, as shown in FIG. 1, the installer 
1003 can be loaded with the ArmCode program 1014 
straightforwardly to thereby develop the same to a corre- 
sponding machine language program. 

[0131] The installer 1003 is destined for generating the 
machine language program for the computer of the machine 



type A hereinafter referred to as the machine A. On the other 
hand, another installer 1015 serves to generate a machine 
language program 1016 for a machine B 1017 by using 
specifications information 1018 of the target machine B. In 
this manner, the translation system now according to the 
present invention is capable of generating from the same 
linked ArmCode program 1009 or the single ArmCode 
program 1014 a plurality of machine language programs 
such as exemplified by the machine language programs 1011 
and 1016 for a plurality of target machines such as exem- 
plified by the computers A 1012 and B 1017 to thereby allow 
these target machines to execute the relevant programs, 
respectively. As will be appreciated from the above descrip- 
tion, the translation system according to the invention can 
generate from the same ArmCode program a plurality of 
machine language programs for a plurality of target 
machines or computers of the specifications differing from 
one another, an example of which will hereinafter be 
described in more detail by reference to FIGS. 31 to 35. 

[0132] FIG. 2 is a diagram showing an exemplary struc- 
ture of an abstract register machine compiler (generally 
denoted by 3100) according to the embodiment of the 
present invention. Referring to the figure, a source program 
3102 undergoes at first a syntax analysis and a semantic 
analysis by a syntax/semantic analysis section 3104 of the 
compiler 3100 to be translated into an intermediate language 
program 3106, while information of a variety of symbols 
used in the source program 3102 is entered in a symbol table 
3108. An intermediate language optimalization section 3110 
of the compiler 3100 performs a control flow analysis and a 
data flow analysis on the intermediate language program 
3106 to thereby realize a global optimalization, as a result of 
which there is generated an ArmCode program 3112 as a 
sequence of abstract register machine code instructions prior 
to an optimalization processing 3114. Subsequently, the 
optimalization processing 3114 on the ArmCode program is 
carried out to generate an abstract object program 3116 as 
the optimalized ArmCode-R instruction sequence. Concern- 
ing the methods of the syntax analysis, the semantic analy- 
sis, the control flow analysis, the data flow analysis and the 
global optimalization, reference may be made to " A. V. Aho, 
R. Sethi and J. D. Ullman: Compilers; Principles, Tech- 
niques and Tools", Addison-Wesley Publishing Co., 1986, 
pp. 1-24. 

[0133] One of the aspects of the present invention can be 
seen in a structure of the abstract register machine code 
ArmCode instruction. In other words, this ArmCode instruc- 
tion has a structure and contents which are suited for the 
processings contemplated by the present invention, i.e., a 
high speed translation of the abstract object program to a 
machine language program suited for the target machine 
upon loading of the abstract object program. A system of the 
ArmCode instructions is common to a number of reduced 
instruction set computers (RISC) machines and it will here- 
inafter be referred to as the ArmCode-R (Abstract register 
machine Codes for RISC machines) system. 

[0134] The ArmCode-R instructions are suited for the 
computers having the features mentioned below. 

[0135] (1) Operations are performed only between or 
among the registers. 

[0136] (2) Memory access is made only with the 
load/store type instruction. 
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[0137] (3) A base register is incorporated. 

[0138] (4) Registers which can be employed for 
operations are not a few (sixteen or more). 

[0139] (5) Immediate constants are available. 

[0140] (6) All the instructions can each be repre- 
sented by one word (32 bits). 

[0141] Each of the ArmCode-R instructions is not the very 
machine instruction for a specific target computer but can 
easily be translated to the machine instruction. The repre- 
sentation format of each ArmCode-R instruction is charac- 
terized by the features mentioned below. 

[0142] (1) The register is not represented as a physi- 
cal register but as a abstract register. 

[0143] (2) A memory address is specified based on 
not a numerical value address but a symbol name. 

[0144] (3) The memory is addressed on a byte basis. 

[0145] (4) The instruction is of a fixed length. 

[0146] In the following description, it should be under- 
stood that the expression "ArmCode" represents " Arm Code - 
R" unless specified otherwise. 

[0147] FIG. 3 is a diagram for illustrating correspondence 
relations between the ArmCode program and the machine 
language program for the target machine shown in FIG. 1. 
As mentioned previously, the source program 2910 under- 
goes the translation and linkage processing through a com- 
piler/linker section 2912 to be translated into an abstract 
object program 2920, which is represented by an ArmCode 
instructions sequence composed of instructions for the 
abstract register machine. 

[0148] Each ArmCode instruction is similar to one for a 
model machine or computer common to many of the cur- 
rently used computers, and include an abstract operator 
2921, an abstract register designation 2923 and an abstract 
memory/constant designation 2925 as typical or represen- 
tative items. The abstract operator represents the content of 
one of instructions incorporated universally in many com- 
puters, such as load/store for instructing data transfers 
between a memory and a register, an arithmetic operation as 
addition or subtraction and others. The abstract register 
name designation indicates a register in the abstract register 
machine, wherein no limitation is imposed to the number of 
the abstract registers, differing from a case of a real com- 
puter. The abstract memory/constant designation 2925 can 
be handled similarly to that for an memory address and a 
constant in the real computer except that the former is free 
from any limitation in respect to the address and magnitudes 
of a value of the constanl. 

[0149] The ArmCode instruction sequence 2920 is trans- 
lated into a machine language instruction sequence for a 
target machine through the installer provided in association 
with the target machine. By way of example, the instruction 
sequence 2920 shown in FIG. 3 is translated into a machine 
language instruction sequence 2950 for a machine A when 
an installer 2930 for the machine type A is used while it is 
translated into a machine language instruction sequence 
2960 for a target machine B when an installer 2940 for the 
target machine B is used. The ArmCode instructions and real 
machine instructions are not always in one-to-one corre- 
spondence. In general terms, an instruction sequence includ- 



ing m ArmCode instructions is translated into an instruction 
sequence including n real machine instructions. An operator, 
a register designation and a memory/constant designation 
contained in each machine instruction are inherent to the 
machine to which that machine instruction is oriented. For 
example, an operator 2951, a register designation 2953 and 
a memory/constant designation 2955 of each machine 
instruction of the machine language program 2950 oriented 
for the machine A are inherent to that machine A, while an 
operator 2961, a register designation 2963 and a memory/ 
constant designation 2965 of each machine instruction con- 
tained in the machine language program 2960 for the 
machine B are inherent to that machine B. 

[0150] In the ArmCode instruction there are contained 
machine instruction generating instructions describing 
instructions which are actually to be executed by the target 
computer and structures thereof as well as generation control 
statements for controlling the generation of machine instruc- 
tions, as exemplified below: 

[0151] allocCArlO^cArith^lclO^^^^cOOOOOOO); 

[0152] if(alclO) 

[0153] Load RegMd ArlO Vbase OdDisp v; 

[0154] Add RegCon Aril Noreg OdCi 6; 

[0155] As the machine instruction generating instructions, 
there may be mentioned the following types, which are 
written in an array in the abstract object program, being 
punctuated by semicolons. 

[0156] (1) Corresponding machine language instruc- 
tions: 

[0157] (Load4, Store4, Add, Sub, etc.) 

[0158] (2) Pseudo-instructions representing program 
structures: 

[0159] (Start/Pend, Block/End, Stmt, etc.) 

[0160] (3) Pseudo-instructions for indicating the 
symbol names: 

[0161] (Entry, External, Label, Name, etc.) 

[0162] (4) Pseudo-instructions for designating the 
memory: 

[0163] (Dword, Dconst, Daddr, etc.) 

[0164] (5) Pseudo-instructions for designating the 
symbol information oriented for a debugger or the 
like: 

[0165] (Sinf, etc.) 

[0166] As is shown in FIG. 4, the generation control 
statement includes a conditional statement 3120, an assign- 
ment statement 3122 and a function reference statement 
3124 and equations containing constants and simple vari- 
ables can be used in the statements. As generation control 
functions, there can be used those functions mentioned 
below (refer to 3124 in FIG. 4). 

[0167] (1) Function: "alloc" (abstract register name, reg- 
ister type, discriminant variable, instruction number, pre- 
serve count, priority) 

[0168] This function "alloc" serves for requesting alloca- 
tion to an abstract register designated by a first parameter a 



04/16/2004, EAST Version: 1.4.1 



US 2002/0026633 Al Feb. 28, 2002 

8 



physical register of the type designated by a second param- 
eter. The instruction number is an ordinal number identify- 
ing an abstract register using instruction in precedence to the 
allocation request. The preserve count represents the number 
of the registers to be preserved even after the register 
allocation. The priority represents the level of priority at 
which the register is to be allocated. The value of the 
discriminant variable designated by a third parameter is set 
to "1" when a physical register can be allocated at the time 
of the register allocation request while it is set to "0" when 
allocation of the physical register is impossible. 

[0169] (2) Function: free (abstract register name) 

[0170] This function serves for making free (deallocating) 
the physical register from the abstract register designated by 
the first parameter. 

[0171] The priority for the register allocation is repre- 
sented by a bit vector. The abstract register using instruc- 
tions are assigned with the sequential instruction numbers, 
the abstract register to be used after p instructions as counted 
from the current instruction is correspondingly assigned 
with a bit vector including one bit of "1" placed after a 
succession of "0s" in a number of (p-1). The priority is 
decided by regarding the bit vector as an unsigned integral 
value such that the unsigned integral value of greater mag- 
nitude represents a higher priority. Accordingly, the priority 
of the abstract register to be used immediately is higher than 
that of the abstract register used subsequently. For the 
abstract register to be used at a plurality of instructions, a bit 
vector resulting from the OR operation of those correspond- 
ing to the plural instructions is assigned. Whenever progress 
is made from the current instruction, the bit vector is shifted 
to the left by one bit. The leftmost overflowed bit occurring 
upon shifting to the left is discarded with the rightmost bit 
being supplemented with "0". Accordingly, the priority of an 
abstract register becomes highest immediately before the use 
of that abstract register and is lowered after having passed 
the instruction where the abstract register is used. 

[0172] The bit vector representing the priority is not 
restricted to such structure in which the bit "1" is assigned 
to one instruction. By way of example, an abstract register 
using instruction sequence may be segmentalized into seg- 
ments each of a fixed length, and the segments are assigned 
with bits in one-to-one correspondence such that the bit is set 
to the value "1" when an abstract register of concern is used 
in the segment to which the abovementioned bit is assigned 
while otherwise being set to "0". In this manner, it is 
possible to express with a bit vector of a shorter length the 
using state of a register in the long instruction sequence. By 
setting the length of the segment to "1" (unity), the corre- 
spondence relation described above can be realized. 

[0173] In the case of an abstract register used through or 
in a loop, it is assumed that the register is used again or 
repetitively at an interval corresponding to a length of the 
loop (or one^severalth of the length of the loop), and an 
original bit vector is shifted to the right by an adjust count 
corresponding to the loop length (or one-severalth thereof) 
and the shifted bit vector is arithmetically added to the 
original bit vector. A resulting sum is used as the bit vector 
representing the priority of the abovementioned register. 

[0174] With the function "alloc" for allocating the physi- 
cal registers to the abstract registers, the priorities mentioned 



above are designated. The allocation is performed when the 
number of the physical registers capable of accommodating 
the abstract registers having the designated priorities are 
available, while otherwise the allocation is not performed. 
The priority allocated previously to an abstract register 
becomes higher as the instruction which the register is used 
becomes closer while the former becomes lower beyond the 
instruction using that register. Thus, performance of the 
allocation can be determined by comparing the priority of a 
register with the priorities of the other registers. Overflowed 
abstract registers not allocated with the physical registers 
because of their low priorities are allocated to the memory 
areas. Concerning the priority, description in detail will be 
hereinafter be made by reference to FIG. 9. 

[0175] FIG. 5 A is a view for illustrating a format of the 
ArmCode-R instruction. As can be seen in this figure, each 
of the ArmCode-R instructions 3130 is composed of fields of 
an operator 3132, an address mode 3134, a first operand 
3136, a second operand 3138 and a third operand 3140, 
respectively, which have the contents mentioned below. 

[0176] Operator: name of the ArmCode-R instruc- 
tion. 

[0177] Address mode: discrimination of operand 
form. 

[0178] 1st operand: register Rl, literal cl or Arm- 
Code address cl. 

[0179] 2nd operand: register R2, literal c2 or Arm- 
Code address c2. 

[0180] 3rd operand: memory address, displacement 
d3, literal c3, label c3, Arm Code address c3, etc. 

[0181] As shown in FIG. 5B, the operands 3136, 3138 and 
3140 are expressed as follows (refer to specifications of the 
machine language instruction generating instruction): 

[0182] Register: abstract register number. 

[0183] Memory Address: absolute address, position 
of a variable name in a symbol table or abstract 
register number representing an address in the 
memory. 

[0184] Displacement: numerical value representing 
displacement relative to a base register. 

[0185] Literal: integer constant (numerical values, 
character code or positions of a character string table 
and a comment table to be subjected to operation). 

[0186] Label: item number of a label table LBL. 

[0187] Arm Code Address: position of instruction 
ArmCode 

[0188] The third operand is expressed in terms of a 
combination of a sub-item indicating type of the operand 
and a sub-item indicating the operand, as follows. 

[0189] Odsym s3: symbol table entry item s3. 

[0190] OdLab c3: label table (LBL) entry c3. 

[0191] Odci c3: intra-instruction scalar constant c3. 

[0192] OdCL c3: Intra-memory scalar constant indi- 
cated by c3. 

[0193] OdCS c3: string constant c3. 
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[0194] OdGvar s3: temporal variable s3 generated by 
the compiler. 

[0195] OdDisp c3: displacement c3 

[0196] OdNo Null: indication of absence of the third 
operand. 

[0197] The first operand 3136 indicates a store destination 
position of the execution result in the case of the instruction 
for a loading operation and an computing operation while it 
indicates a register which holds the data to be stored in the 
case of the instruction for a storing operation. In the case of 
a conditional branch instruction, the first operand 3136 
indicates a register holding target data for the condition 
determination. The address mode 3134 indicates the number 
of valid operands and the roles of them. 

[0198] FIG. 6 is a view for illustrating possible combina- 
tions of the address mode 3134 with the first operand 
(operand 1) 3136, the second operand (operand 2) 3138 and 
the third operand (operand 3) 3140 shown in FIG. 5. It can 
be seen from FIG. 6 what roles the operand 1 3172, operand 
2 3174 and the operand 3 3176 play for each of the address 
modes 3170 such as RegReg, RegMI and others. In FIG. 6, 
blank column indicate that the relevant operands are not 
valid. When the operand is a simple register, the value of the 
register is utilized. When the operand represents a constant, 
the value thereof is utilized or set. When the operand 
represents an address register, the content of that address 
register is regarded as a memory address to be accessed. In 
case the operand designates the base register and a displace- 
ment, a value resulting from addition of the content of the 
base register and the displacement is regarded to be a 
memory address upon making access to that operand. In the 
address mode RegRCC, the constants c3 and c4 are regarded 
to be positive integers not greater than "255" and nested in 
the third operand. 

[0199] FIGS. 7 to 12 are views showing specifications of 
the machine instruction generating instruction. Meanings of 
the symbols used in the specifications are as follows. 

[0200] a: address or constant a. When this value 
represents the address, a may be a numerical value c 
indicating the absolute address or a numerical value 
s indicating a position of the symbol table. 

[0201] [a]: content of the register or memory at the 
address a. 

[0202] a A : register or memory pointed by the content 
of the address a (having the address given by the 
content of a). 

[0203] ( ): parenthesized expression is handled as one 
symbol. 

[0204] -*: assigning to right-hand register or vari- 
able. 

[0205] assigning to left-hand register or variable. 

[0206] In the case of the instant embodiment of the present 
invention, there are used the instructions mentioned below. 

[0207] 1) Load instructions 3210 (FIG. 7) 

[0208] Load: Load one word data indicated by the 
operand 2 or 3 in the register indicated by the 
operand 1. 



[0209] LoadB: Load one-byte data indicated by the 
operand 2 or 3 in the register indicated by the 
operand 1 with right justification. 

[0210] Mode-wise processings: 

[0211] RegReg: R1*-[R2] 

[0212] RegMI: R1«-[R2] 

[0213] RegMR: Rl<-[([R2]+d) A ] 

[0214] RegMD: Rl*-[d] 

[0215] RegCon: Rl^c3 

[0216] RegAdr: Rl<-[R2]+d 

[0217] 2) Store instructions 3220 (FIG. 7) 

[0218] Store: Store one- word data of the operand 1 in 
a location indicated by the operand 2 or 3. 

[0219] StoreB: Store the rightmost one byte data of 
the operand 1 in a location indicated by the operand 
2 or 3. 

[0220] Mode-wise processings: 

[0221] RegReg: [R1]^R2 

[0222] RegMI: [Rl]— *R2 A 

[0223] RegMR: [Rl]-*([R2]+d) A 

[0224] RegMD: [Rl]->d 

[0225] 3) Integer-class binary flo ating point instructions 
3230 (FIG. 7) 

[0226] Add: Add the operand 2 to the operand 1, and 
place the result of the addition in the operand 1. Set 
a carry of"!" or "0" in dependence on presence or 
absence of overflow. 

[0227] Sub: Subtract the operand 2 from the operand 

1, and place the result of the subtraction in the 
operand 1. Set a carry to "1" when the operand 2 is 
greater than the operand 1 and otherwise to "0". 

[0228] Mult: Multiply the operand 1 by the operand 

2, and place the result of the multiplication in the 
operand 1. 

[0229] Div: Divide the operand 1 by the operand 2, 
and place the quotient in the operand 1 . 

[0230] UnsAdd: Same as the instruction Add except 
for unsigned addition. 

[0231] UnsSub: Same as the instruction Sub except 
for unsigned substruction. 

[0232] AddC: Same as the instruction Add except 
that the carry is considered in the addition. 

[0233] SubB: Same as the instruction Sub except that 
the borrow is considered in the subtraction. 

[0234] Mode-wise processings: 

[0235] RegReg: ([Rl] op [R2])— Rl 

[0236] RegCon: ([Rl] op c3)^Rl 

[0237] where "op" represents an operator. 
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[0238] 4) Real number-class binary floating point 
instructions 3240 (FIG. 8) 

[0239] AddR: Add the operand 2 to the operand 1, 
and place the result of the addition in the operand 1. 

[0240] SubR: Subtract the operand 2 from the oper- 
and 1, and place the result of the subtraction in the 
operand 1. 

[0241] MultR: Multiply the operand 1 by the operand 
2, and place the result of the multiplication in the 
operand 1. 

[0242] DivR: Divide the operand 1 by the operand 2, 
and place the quotient in the operand 1. 

[0243] Mode-wise processings: 

[0244] RegReg: ([Rl] op [R2])— Rl 

[0245] RegCon: ([Rl] op c3)—Rl 

[0246] where "op" represents an operator. 

[0247] 5) Binary logical instructions 3250 (FIG. 8) 

[0248] And: Execute an AND operation of the oper- 
and 1 and the operand 2 and place the result of the 
AND operation in the operand 1. 

[0249] Or: Execute an OR operation of the operand 1 
and the operand 2, and place the result of the OR 
operation in the operand 1. 

[0250] Xor: Execute an XOR or exclusive OR opera- 
tion of the operand 1 and the operand 2, and place the 
result of the XOR operation in the operand 1. 

[0251] Mode-wise processings: 

[0252] RegReg: ([Rl] op [R2])-*R1 

[0253] RegCon: ([Rl] op c3)— Rl 

[0254] where "op" represents an operator. 

[0255] 6) Unary instructions 3260 (FIG, 8) 

[0256] Negate: Invert the sign of the operand 1, and 
place the result of inversion in the operand 1. 

[0257] Not: Invert the bits of the operand 1 , and place 
result of inversion in the operand 1. 

[0258] Mode- wise processing: 

[0259] Regl: Computation is performed on the 
content of the operand 1, the result of which is left 
in the operand 1. 

[0260] 7) Comparison instruction 3270 (FIG. 8) 

[0261] Compar: Compare the content of the operand 
1 with that of the operand 2 and set a condition code. 

[0262] Mode- wise processings: 

[0263] RegReg: If [R1]>[R2] then Gt, if [Rl> 
[R2] then Eq, if [R1]<R2] then Lt. 

[0264] RegCon: If [Rl]>c3 then Gt, if [Rl]=c3 
then Eq, if [Rl]<c3 then Lt. 

[0265] 8) Condition test instructions 3280 (FIG. 8) 

[0266] TZero mode Regl: If "0", set the condition 
code to "Eq" and otherwise to "Ne". 



[0267] TBit mode RegCon: When the bit of [Rl] at a 
position indicated by c3 of the third operand is "0", 
set the condition code to "Eq", while when it is "l'\ 
set the condition code to "Ne". 

[0268] 9) Conditional branch instructions 3290 (FIG. 9) 

[0269] BrEq: When the condition code is "Eq", jump 
to a position indicated by the operand. 

[0270] BrNe: Unless the condition code is "Eq", 
jump to a position indicated by the operand. 

[0271] BrGt: When the condition code is "Gt", jump 
to a position indicated by the operand. 

[0272] BrGe: When the condition code is "Gt" or 
"Eq", jump to a position indicated by the operand. 

[0273] BrLe: When the condition code is "Lt" or 
"Eq", jump to a position indicated by the operand. 

[0274] BrLt: When the condition code is "Lt", jump 
to a position indicated by the operand. 

[0275] In any of the cases mentioned above, the control is 
made to an immediately succeeding instruction unless the 
condition is met. 

[0276] Mode- wise processings: 

[0277] Const: Position indicated by the label table 
LBL[c3] is the address of the jump destination. 

[0278] RegR: [R2]+d is the address of the jump 
destination. 

[0279] 10) Unconditional branch instruction 3300 
(FIG. 9) 

[0280] Jump: Jump to a position indicated by the 
operand. 

[0281] Mode- wise processings: 

[0282] Const: Position indicated by the label table 
LBL[c3] is the address of the jump destination. 

[0283] RegR: [R2]+d is the address of the jump 
destination 

[0284] 11) Subprogram reference instruction 3310 
(FIG. 9) 

[0285] Call: After recording a return address, jump to 
a subprogram indicated by the operand. 

[0286] Mode-wise processings: 

[0287] RegMR: Placing the return address in Rl, 
jump is made to the address [R2]+d. 

[0288] RegMD: Placing the return address in Rl, 
jump is made to a subprogram address indicated 
by the label table LBL[c3]. 

[0289] Regl: After stacking the return address, 
jump to the address [Rl]. 

[0290] 12) Return instruction 3320 (FIG. 9) 

[0291] Return: Jump to the return address recorded 
by the instruction "Call" from the subprogram indi- 
cated by the operand. 
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[0292] Mode- wise processings: 

[0293] Regl: Jump to the return address recorded 
in Rl. 

[0294] RegO: Fetching of the return address 
stacked by the instruction "Call" through UFO 
scheme and jump to the fetched return address. 

[0295] 13) Shift instructions 3330 (FIG. 10) 

[0296] These instructions are each to shift the content of 
the first operand Rl to the left or right by a bit number n 
indicated by the second or third operand. 

[0297] ShiftL: Shift Rl to the left by n bits with the 
rightmost n bits being "0s". 

[0298] Shift R: Shift Rl to the right by n bits with the 
leftmost n bits being "0s'\ 

[0299] Mode- wise processings: 

[0300] RegCon: Rl represents a target register (i.e, 
register of concern) with c3 representing the bit 
number for the shift. 

[0301] RegReg: Rl represents a target register 
with [R2] representing the bit number for the shift. 

[0302] 14) Rotation instructions 3340 (FIG. 10) 

[0303] These instructions are each to rotate the content of 
the first operand Rl to the left or to the right by a number 
n of bits indicated by the second or third operand. 

[0304] RotL: Rotate Rl to the left by n bits. 

[0305] RotR: Rotate Rl to the right by n bits. 

[0306] Mode-wise processings: 

[0307] RegCon: Rl represents a target register 
with c3 representing the bit number for the rota- 
tion. 

[0308] RegReg: Rl represents a target register 
with [R2] representing the bit number for the 
rotation. 

[0309] 15) Bit manipulation instructions 3350 (FIG. 
10) 

[0310] GetBit RegCC: Place the c3-bit data starting 
from the bit c2 of Rl in Rl with right justification. 
Left-hand bit portion of Rl is "0". 

[0311] GetBit RegRCC: Place the c3-bit data starting 
from the bit c2 of R2 in Rl with right justification. 
Left-hand bit portion of Rl is "0". 

[0312] PutBit RegRCC: Place the rightmost c4-bit 
data of Rl in a c4-bit length field starting from the bit 
c3 of R2. Content of other bit field remains 
unchanged. 

[0313] 16) Data conversion instructions 3360 (FIG. 10) 

[0314] ItoR RegReg: Instruction for integer-to-reaJ 
conversion of the content of Rl, the result being 
placed in R2. 

[0315] Rtol RegReg: Instruction for real-to-integer 
conversion of the content of Rl, the result being 
placed in R2. 



[0316] ItoD RegReg: Instruction for integer-to- 
double real conversion of the content of Rl, the 
result being placed in R2. 

[0317] Dtol RegReg: Instruction for double real-to- 
integer conversion of the content of Rl, the result 
being placed in R2. 

[0318] 17) Status switch instructions 3370 (FIG. 11) 

[0319] SaveSt RegMR: Save the current processor 
status in the memory, (saving information: program 
counter, status code, mask, etc.) 

[0320] LoadSt RegMR: Restore the processor status 
in accordance with information stored in the 
memory. 

[0321] 18) No-operation instruction 3380 (FIG. 11) 

[0322] Nop RegO: No execution of operation with a 
machine instruction occupying one word. 

[0323] 19) Program structure representing pseudo-in- 
structions 3390 (FIG. 11) 

[0324] Start Contl OdSym: Pseudo-instruction for 
starting object having a name (of the symbol table) 
indicated by s3. 

[0325] SubP Contl OdSym: Pseudo-instruction indi- 
cating the start of a subprogram indicated by s3. 

[0326] Block ContO: Block start pseudo-instruction. 

[0327] End ContO: Block end pseudo-instruction. 

[0328] Loops Contl OdLab: Pseudo-instruction indi- 
cating a head of a loop statement having a label 
indicated by LBL (c3) as a repetition starting point. 

[0329] Loope Contl OdLab: Pseudo- instruction indi- 
cating trail of a loop statement having a label indi- 
cated by LBL (c3) as a repetition starting point. 

[0330] Pend ContO: End of a subprogram or unit. 
(This "End" instruction is followed by "Define Stor- 
age" and "Define Constant*' instructions and finally 
by "Pend" instruction.) 

[0331] Stmt Contl OdCi: Pseudo -instruction indicat- 
ing a start position of a statement having c3 as the 
statement number. 

[0332] 20) Symbol name indicating pseudo-instructions 
3400 (FIG. 11) 

[0333] Entry Contl OdSym: Pseudo-instruction indi- 
cating a name (of the symbol table) indicated by s3 
as an entry name. 

[0334] Extern Contl OdSym: Pseudo-instruction 
indicating that a name (of symbol table) indicated by 
s3 is an external name. 

[0335] Label Contl OdLab: When c3 represents a 
LBL table number (user label) having a symbol 
table, the pseudo-instruction defining the name of the 
symbol table as the table name. When c3 represents 
a LBL table number (generated label) having no 
symbol table, this pseudo-instruction defining the 
generated label name 536 n as the label name. 
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[0336] Label contl OdCL: Pseudo-instruction defin- 
ing a constant name WCm as the label name, when 
c3 is LRG table number m representing a memory 
constant. 

[0337] Label Contl OdGvar: Pseudo -instruction 
defining a generated variable name ¥¥Tk as the label 
name, when s3 is symbol table number k represent- 
ing a generated variable. 

[0338] Name Contl OdSym: Pseudo -instruction 
equating a name (of symbol table) indicated by s3 to 
the name of immediately preceding OpLabeL 

[0339] 21) Memory designating pseudo-instructions 
3410 (FIG. 12) 

[0340] Dconst Contl OdCi: Constant definition for 
defining c3 as an integer constant value. 

[0341] Dconst Contl OdCS: Constant definition for 
regarding c3 as a one -word character string. 

[0342] Dconst Contl OdCS: Constant definition for 
regarding c3 as a one -word character string constant. 

[0343] Dword Contl OdCi: "Define Storage" pseudo- 
instruction for securing a memory area of c3 words. 

[0344] Daddr Contl OdSym: "Define Address" 
pseudo-instruction for the name (of symbol table) 
indicated by s3. 

[0345] MCode Contl OdCi: Pseudo-instruction for 
generating a machine language MRT[c3] indicated 
by c3. 

[0346] 22) Pseudo-instructions 3420 designating 
debugger-oriented symbol information, etc. (FIG. 12) 

[0347] Plnf Contl OdCi: Pseudo-instruction indicat- 
ing information of a program characteristic informa- 
tion table resident at a position indicated by c3. 

[0348] Slnf Contl OdCi: Pseudo-instruction indicat- 
ing symbol information at a position indicated by c3. 

[0349] FIG. 13 is a view showing an example of the 
source program 3102 which is inputted to the compiler 3100 
shown in FIG. 2. The source program 3102 is composed of 
a declaration statement 3610 designating a global variable, 
designation of a name of a function 3614, a declaration 
statement 3616 of local variables in the function, a sequence 
of executable statements beginning with an executable state- 
ment 3620, etc. The numbers such as "1" positioned at the 
head of the declaration statement 3610, "10" at the head of 
the executable statement 3620 and the like represent the 
identification numbers of the respective statements. FIGS. 
14 to 16 show in combination an example of the ArmCode 
instruction sequence resulting from the translation of the 
source program shown in FIG. 13. The illustrated instruc- 
tion sequence is not yet subjected to the optimalization 
processing. A pseudo-instruction 3700 designating symbol 
information in FIG. 14 corresponds to the declaration state- 
ment 3610 in the source program shown in FIG. 13. 
Similarly, a pseudo -instruction 3702 corresponds to the 
declaration statement 3616. Further, an ArmCode instruction 
sequence beginning with the executable statement 3710 
shown in FIG. 14 corresponds to the sequence of executable 
statement beginning with the statement 3620 of the source 
program shown in FIG. 13. 



[0350] Now, description will be made in more concrete 
concerning the priorities of the registers with reference to 
FIG. 14 to FIG. 18. The instructions which use abstract 
registers in this ArmCode program are 3720, 3722 and so 
forth with an asterisk "*" at the head. The instruction 
"alloc"3710 requests the allocation of a physical register to 
an abstract register named "Vbase" with the priority desig- 
nated as "0x62489700+0x00224897". The abstract register 
named Vbase is used by the instructions 3722, 3734, 3758, 
3770, 3790, 3828, 3846, 3850, 3856 and 3860. 32 instruc- 
tions from the instruction "alloc"3710 are checked to deter- 
mine whether or not these are an abstract register using 
instruction. Based on the checked result, a bit vector is 
generated in which "Is" are placed at the bit positions 
corresponding to the instructions which use the abstract 
register Vbase while "Os" are placed at the positions of the 
instructions which do not use the abstract register. As a 
result, the bit vector is represented by 
"01100010010010001001011100000000", which can be 
rewritten as "0x62489700" in the hexadecimal notation, as 
is shown in the instruction "alloc"3710. In the case of the 
program shown in FIGS. 14 to 16, there exists a loop from 
the instruction 3868 to the instruction 3728. This loop 
includes 23 instructions which use the abstract register. In 
the case of the instant embodiment, the number of the 
instructions using the abstract register and contained in this 
loop is divided by "3", and a value associated with the 
quotient when the remainder is "0" or (the quotient +1) when 
the remainder is not zero is defined as the adjust number. The 
bit vector of the abstract register "Vbase" used in the loop 
is represented by setting the second bit to "0" in the bit 
vector 3910, i.e. "00100010010010001001011100000000". 
By shifting this bit vector to the right by a number "8" 
resulting from division of "23" by "3" with the remainder 
being rounded up, there is obtained 
"00000000001000100100100010010111", as shown in con- 
junction with the instruction 3912, which is represented by 
"0x00224897" in the hexadecimal notation. Accordingly, 
the priority of the "Vbase" allocation request is represented 
by a number "0x62489700+0x00224897", i.e., a sum of the 
addition of "0x62489700" and "0x00224897" as unsigned 
integers, as shown in the instruction "alloc"3710 in FIG. 14. 
Through a similar procedure, the priority for the abstract 
register Ar5 can be computed, as is shown at 3918 and 3920 
in FIG. 17. 

[0351] The register allocation priority is not fixed but 
shifted to the left as the instructions are checked, as 
described previously. For example, at the position of the 
instruction 3732 located at the head of the loop which 
follows after the two register using instructions, the priori- 
ties of the registers "Vbase" and "Ar5" are shifted by two 
bits, respectively, resulting in that the priority of the register 
"Vbase" is "0x89225C00+0x0089225C, as shown at 3914 
and 3916 in FIG. 17, while that of the register "Ar5" is 
"0x44110000+0x00441100", as shown at 3922 and 3924. 
This priority is compared with the priority "OxEOOOOOOO" of 
the register "Ar6" whose allocation is requested by the 
instruction 3732. 

[0352] FIG. 18 is a flow chart for illustrating a procedure 
for generating the priority bit vector in the register allocation 
mentioned above. The priority bit vector of a register r is 
assumed to be represented by Pr. This bit vector Pr is first 
reset (step 3930). A succeeding ArmCode instruction is 
fetched (step 3932) and checked whether it is the loop start 
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instruction (step 3934). When it is not the loop start instruc- 
tion, then it is checked whether the fetched ArmCode 
instruction is the register using instruction (step 3936). 
When the answer of this decision step 3936 is affirmative 
(Y), the priority bit vector Pr of the register r is shifted to the 
left by one bit (step 3938). Subsequently, it is checked 
whether or not the register r is use (step 3940). When the 
register r is used, "1" is set at the rightmost bit of the priority 
bit vector Pr (step 3942). If otherwise (N), the rightmost bit 
of the bit vector Pr is set to "0" (step 3943). When the 
succeeding ArmCode instruction is a loop exit instruction or 
an instruction to free the register r, computation of the 
priority bit vector for the register r comes to an end (step 
3944). If otherwise, the next ArmCode instruction is fetched, 
and the processing described above is repeated. 

[0353] When the ArmCode instruction as fetched in the 
step 3932 is determined to be the loop start instruction (step 
3934), the priority bit vector of the register r is assumed to 
be represented by Lr within the loop under consideration and 
determined through the same procedure as described above 
(steps 3930 to 3944). Subsequently, the number of the 
abstract register using instructions contained in the loop is 
divided by three with the remainder. If there is any remain- 
der, the quotient is rounded up. Then, the priority bit vector 
Lr is adjusted by shifting it to the right by a number of bits 
corresponding to the quotient or the rounded up quotient 
resulting from the above determination (step 3947). There 
after, the adjusted priority bit vector Lr is added to the 
priority bit vector Pr of the instruction sequence including 
the loop (step 3948). In this way, the allocation priority bit 
vector Pr for one abstract register r can be computed. This 
processing is executed for each of the abstract registers. 

[0354] FIG. 19 is a flow chart illustrating a procedure of 
the object optimization for enhancing the efficiency of 
execution of a machine language program obtained from an 
ArmCode program according to an embodiment of the 
present invention. At first, an ArmCode instruction sequence 
of the ArmCode program is divided into a plurality of basic 
blocks by punctuating the sequence at flow-in points and 
branching points of the control (step 3952). Each of the basic 
blocks has a feature that it is executed in a beeline from the 
start to last instructions. In the case of the example illus- 
trated in FIGS. 14 to 16, the instructions 3712 to 3722, 3724 
to 3748, 3750 to 3778 etc. constitute the basic blocks, 
respectively, and a generation control instruction "bblock" 
indicating the inter-block link relation is added at the head. 
In the case where a certain basic block b is necessarily 
executed immediately after the execution of other basic 
block a, a basic block sequence which allows execution of 
the block b in succession to the basic block a to which the 
block b is linked is referred to as the extended basic block. 
By way of example, for the basic blocks starting from the 
instructions 3724, 3750 and 3780, respectively, a resultant 
block obtained by linking together these three basic blocks 
represents an extended basic block, because in each of the 
abovementioned basic blocks, the succeeding instruction is 
neccessarily executed immediately after the preceding 
instruction. The basic block beginning with the instruction 
3840, for example, where extension is impossible because 
the preceding basic block and the succeeding basic block 
can not definitely be established, is defined by itself as one 
extended basic block. Subsequently, a common expression 
or equation in the extended basic block is deleted. To this 
end, starting from the first extended basic block (step 3954), 



the common equation in the extended basic blocks is picked 
out (step 3956). The succeeding common equation is 
replaced by the content of a register or a variable represent- 
ing the result of the common equation picked out preced- 
ingly (step 3958). This procedure is repeated until the last 
extended basic block has been reached (steps 3960, 3962), 
The abovementioned processing can be carried out by 
applying the algorithm disclosed in the Aho, Sethi and 
Ullman mentioned hereinbefore to the ArmCode instruction 
sequence. 

[0355] FIGS. 20 to 21 are views showing in combination 
an ArmCode instruction sequence generated as the result of 
the above-mentioned processing of the instruction sequence 
shown in FIGS. 14 to 16 and the optimalization processing 
described below. Referring to FIGS. 20 and 21 together 
with FIGS. 14 to 16, the optimalization processing will now 
be elucidated in concrete. In FIGS. 14 to 16, the computation 
instructions 3758 and 3760 for computing the value of the 
abstract register Ar8, the computation instructions 3790 and 
3792 for computing the value of the abstract register Arl2 
and the computation instructions 3828 and 3830 for com- 
puting the value of abstract register Arl5 are same as the 
computation instructions 3734 and 3736 for determining the 
value of the abstract register Ar6, while the instruction 3764 
for determining the value of the abstract register Ar9 is same 
as the instruction 3740 for determining the value of the 
abstract register Ar7. Similarly, the instruction for determin- 
ing the register value Arl3 is same as that for the register 
value Aril, while the instructions for determining the reg- 
ister values Arl5 and Arl6 are same as that for determining 
the value of Ar5. Consequently, in the instruction 4098, the 
abstract registers Ar6 and Aril are reused, while in the 
instruction 4076, the register Ar7 is reused with the register 
Ar5 being reused in the instructions 4108, 4110 and 4112, as 
shown in FIGS. 20 and 21. In this manner, these abstract 
registers are replaced by those having the identical values, 
respectively, whereby the instructions for determining the 
values of the abstract registers Ar8, Arl2, Arl5, Ar9, Arl3, 
Arl5 and Arl6 are deleted. Since the use frequencies of the 
abstract registers as well as the positions at which they are 
used change in accompanying the replacements mentioned 
above, the order of the priorities allocated to these abstract 
registers will vary correspondingly. The instructions 
"alloc"4028 etc. shown in FIGS. 20 and 21 indicate the 
processings mentioned above. 

[0356] An ArmCode program shown in FIGS. 20 and 21 
is derived from the ArmCode program shown in FIGS, 14 to 
16 by moving the intra-loop invariant equation outside of the 
loop and by effecting a branch optimalization. FIG. 22 is a 
Flow chart for illustrating the processing to this end. More 
specifically, referring to the figure, the loops are detected by 
a flow analysis (step 4202). Thereafter, starting from the 
innermost loop (step 4204), the intra-loop invariant equa- 
tions are detected (step 4206) to be subsequently moved to 
the position immediately before the start of the loop (step 
4208), evading repetition of the same computation within 
the loop. This processing is repetitively executed up to the 
outermost loop inclusive (steps 4210, 4212). Since the 
values of the abstract registers ArlO, Aril and Arl7 shown 
in FIGS. 14 to 16 remain invariable in the loop which starts 
from the instruction 3728 and ending at the instruction 3874, 
the instructions 3770, 3786 and 3860 for computing the 
values of these registers are moved to the position before the 
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loop. The instructions moved in this way are indicated at 
4038, 4044 and 4050, respectively, in FIGS. 20 and 21. 

[0357] Further, referring to FIGS. 14 to 16, the branch 
destination L3 (3806) of the conditional branch instruction 
BrGe (3778) includes an unconditional branch instruction 
(3808) to L5. Accordingly, by determining the branch des- 
tination of the conditional branch instruction (3778) as L5, 
the unconditional branch instruction (3808) at L3 can be 
deleted. Additionally, the jump destination L4 (3812) of the 
unconditional branch instruction "Jump" (3802) includes the 
unconditional branch instruction (3814) to L5. Accordingly, 
by determining the branch destination of this instruction 
"Jump" as L5, the unconditional branch instruction (3814) at 
L4 can be deleted as well. As the result of the processings 
for enhancing the ArmCode instruction sequence execution 
efficiency for the abstract register machine as described 
above, there is obtained the ArmCode program shown in 
FIGS. 20 and 21. 

[0358] Next, description will be turned to a method of 
generating a machine instruction train for a real machine 
from an ArmCode instruction sequence i.e., ArmCode -R 
program generated in the manner described above. 

[0359] FIG. 23 is a view showing the types of the physical 
registers used in a machine A. More specifically, it is shown 
at 4260 that 8th to 23rd physical registers can be used for 
arithmetic operations "RcArith". Similarly, a "RcAddr" 
shown at 4262 indicates a register usable for address cal- 
culation, "RcSect" at 4264 indicates a register used for 
indicating a section start position. Further, "RcReturn" at 
4266 indicates a register used for restoration from a sub- 
program, "RcFuncval" at 4268 indicates a register used for 
placing therein a function value, "RcParm" at 4270 indicates 
a register used for placing therein a parameter, "RcNosave" 
at 4272 indicates a register which is neither saved nor 
restored upon reference to a subprogram, "RcTemp" at 4274 
indicates a register which is used temporally, "RcFixed" at 
4276 indicates a register having the usage fixed, and 
"RcAny" at 4278 represents all the registers which are 
subject to the register allocation. 

[0360] FIG. 24 is a view for illustrating a part of corre- 
spondence relations between the physical registers of the 
machine A and the abstract registers. It is assumed that the 
number of the abstract registers 4280 is arbitrary while the 
number of the physical registers 4282 of the machine A is 
limited to "32". As can be seen in FIG. 24, there are 
established correspondences between the abstract registers 
(4284) "FuncvalO" and "Funcvall" for placing therein 
function values and the physical registers "2" and "3", as 
indicated by 4290 and 4291. Similarly, correspondences are 
established between the abstract registers (8285) "ParamO", 
"Paraml", . . . , "Paramp" for placing parameters therein and 
the physical registers "4" to "7", as indicated at 4291 and 
4292, between the abstract registers for arithmetic opera- 
tions (4286) "ArO", "Arl", . . . , "Arq" and the physical 
registers "8" to "23", as indicated by 4292 and 4294, 
between the abstract registers (4287) "AddrO", 
"Addrl", . . . , "Addrr" for the address calculation and the 
physical registers "16" to "23", as indicated by 4293 and 
4296, and between the abstract registers (4288) "SectO", 
"Sectl", . . . , "Sects" for indicating the section start 
positions and the physical registers "20" to "23", as indi- 
cated by 4295 and 4297, respectively. At this juncture, it 



should be noted that the number (p+1) of the abstract 
registers for parameters, the number (q+1) of the abstract 
registers for arithmetics operations, etc. are not restricted to 
the number of the physical registers but depend on the 
numbers of those registers which are required by the source 
program. As to the manner in which the abstract registers are 
allocated to the physical registers of the target machine, 
description will be made later on by reference to FIGS. 26 
to 29. 

[0361] FIG, 25 is a diagram for illustrating a system for 
realizing the machine language generation through a pattern 
matching procedure. The illustrated system includes a pat- 
tern matching section 4556 and a table 4630 of machine 
instruction generating rules and operates to generate a 
machine language program 4650 in response to an ArmCode 
instruction sequence 4640 of an ArmCode program as 
inputted. The table 4630 stores input patterns and corre- 
sponding output patterns in one-to-one correspondence. 
Assuming now that one instruction 4602 is fetched from the 
instruction sequence 4640 an input pattern which coincides 
with the one instruction 4602 is searched for in the table 
4630. In the case of the illustrated example, it is assumed 
that the instruction 4602 coincides with the input pattern i of 
the i-th generating rule 4632. Accordingly, a machine 
instruction 4652 is generated from the input instruction 4602 
in accordance with the generation pattern i of the i-th 
generating rule 4632. At this time, processing such as 
replacement of the abstract register by the physical register, 
modification of the generating rule in consideration of the 
environmental conditions or the like is performed, as will be 
described hereinafter by reference to FIGS, 29 to 35. 

[0362] FIG. 26 is a view showing a part of the machine 
instruction generating rules oriented for the machine A. As 
will be seen in the figure, the generating rules are parenthe- 
sized by braces "{}" after a corresponding ArmCode instruc- 
tion sequence as shown at 4300, 4312 and others. Genera- 
tion of the corresponding machine instructions is same as in 
C language. A symbol "|" affixed at the head as shown at 
4312, 4316 and others represents alternative between the 
sequences. The operands Regl, C, V, and others for the 
abstract register machine are expressed by SRegl, SC, $V 
and the like in the braces "{}". 

[0363] In more concrete, manners of generating a machine 
instruction for the machine A in correspondence to an 
abstract register machine instruction indicated at the first 
row 4300 for loading a constant are shown as rows of 
statements parenthesized by the braces "{}", starting from 
the row 4302. More specifically, the parenthesized state- 
ments describe that if the constant is "0" (zero) or greater 
than "0" and smaller than "65536", a machine instruction is 
to be generated in accordance with the statement 4304 and 
if otherwise the machine instructions are to be generated in 
accordance with the statements 4308 and 4310. FIG. 28 
shows a machine instruction 4500 which has been generated 
by applying this rule to the instruction 4030 shown in FIG. 
20. In the case of this example, the abstract registers are 
allocated with the physical registers in correspondence to the 
types of the abstract registers, as exemplified by allocation 
of the physical register $08 to the abstract register Ar5, the 
physical register S17 to the abstract register Ar6 and so forth, 
as shown in FIG. 27 at 4400. 

[0364] Unless the number of the physical registers as 
requested are available, the allocation of the physical reg- 
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isters is not performed in response to the request by the 
instruction "alloc" but the physical register allocation pro- 
cessing is again executed at the time when the physical 
registers are actually used. By way of example, the instruc- 
tion 4046 shown in FIG. 20 indicates a physical register 
allocation request for the abstract register Arl7. However, 
this instruction contains a designation that the number of the 
physical registers to be preserved even after the allocation is 
"2". Besides, the priority of this instruction 4046 is rela- 
tively low. Accordingly, it may occur that no physical 
register allocation is effected at this time point. In this case, 
the condition 4048 is not fulfilled. Accordingly, though no 
load instruction is generated in response to the instruction 
4050, only the fact that the abstract register Arl7 represents 
the value of a variable n is recorded. Consequently, the 
comparison instruction 4112 which uses the abstract register 
Arl7 is not yet allocated with any physical register. Thus, 
the physical register allocation processing is again executed 
upon processing this ArmCode instruction. At this time, the 
abstract register Arl7 has the highest priority to allow the 
allocation to be executed, whereby the load instruction for 
setting the value of the register Arl7 is also generated. 
Assuming in conjunction with this example that the abstract 
register Arl7 is allocated with the physical register $09, the 
instruction for loading the value of the variable n is gener- 
ated in accordance with the record made at 4046. As a result 
of this, there are generated in place of the instruction 4526 
in FIG. 28 

[0365] "sub $24, $08, $12" 

[0366] two instructions: 

[0367] "lw $09, n($16) J ', and 

[0368] "sub $24, $08, $09". 

[0369] In this way, if the abstract register allocated with no 
physical register is to be used, allocation of the physical 
register as well as setting a value there in is performed by 
using a function "gen" contained in the machine instruction 
generating rules shown in FIG. 26 such as the rule 4304 and 
others. 

[0370] The installer for the machine A generates the 
machine language program for the machine A from the 
abstract object program in the manner described above. At 
that time, selection of the optimal machine instruction 
sequence and the optimal utilization of the physical registers 
are attempted in conformance with the target machine, in the 
case of the illustrated example, such measures are adopted 
that the machine instruction sequence to be generated is 
changed in conformance with the magnitude of a constant in 
accordance with the generating rule 4302 shown in FIG. 26 
and that correspondences to the abstract registers are estab- 
lished by taking into account the number and the types of the 
usable physical registers, thereby allowing the physical 
registers such as $11 placed with a value to be used as many 
times as possible. In case there make appearance common 
equations in the generated machine language program in 
accompanying the expressions inherent to tbe target 
machine, the optimalization processing such as deletion of 
repetitive computation for the common equation may be 
performed by resorting to the processing described herein- 
before in conjunction with FIG. 19. 

[0371] FIG. 29 is a flow chart for illustrating a processing 
flow of generation of the machine language program. After 



initialization (step 4552), one of the ArmCode instructions 
which constitutes a part of the abstract object program is 
fetched (step 4554), and the pattern matching is performed 
for checking to which of the patterns corresponding to the 
ArmCode instructions described in the machine instruction 
generating rules such as shown in FIG. 26 the fetched 
ArmCode instruction fits (step 4556). In case no fitting 
pattern is found, the matching resultant state is recorded 
(step 4560), and then the succeeding ArmCode instruction is 
fetched. When the fitting pattern is found, preparation for a 
machine instruction is made in accordance with description 
of the machine language lgeneration for the fitting pattern 
(step 4562). When the register allocation is requested for the 
generated machine instructions as described, the register 
allocation processing is performed (step 4564). When the 
memory allocation is requested, the memory allocation 
processing is executed (step 4566). For the request for 
generation of a real machine instruction, the corresponding 
processing is performed (step 4568). When addition of 
control information such as the debug control information 
and others is requested, the control information as required 
is added to the machine language program (step 4570). In 
case the generation control information concerning the reg- 
ister allocation, memory allocation, selection of the instruc- 
tions to be generated and/or the like is requested, the 
corresponding information setting processing is executed 
(step 4572). Subsequently, processing procedure proceeds to 
a next statement contained in the description of the machine 
language generation (step 4576). Execution of the above- 
mentioned processing steps 4566 to 4576 is repeated. When 
the operations) designated in the description of the machine 
language generation has been completed (step 4574), a 
postprocessing for the generation processing for the pattern 
of concern is performed (step 4578). At this time, the 
matching state is altered so as to conform with the current 
state (step 4580), and return is made to the pattern matching 
processing. When it is detected that the abstract object 
program has wholly been processed, the machine language 
generation processing comes to an end (step 4582). 

[0372] FIG. 30 is a schematic block diagram showing an 
internal structure of the installer for generating the machine 
language program from the ArmCode program in the man- 
ner described above. Referring to the figure, the installer 
4530 generates the machine language program 4549 from 
the ArmCode instruction sequence 4531 and the machine 
instruction generating rules 4532 for the target machine of 
concern. The pattern matching is principally effectuated by 
making use of a state transition table. To this end, the 
generating rules 4532 are once transformed into a state 
transiting table 4535 by a state transition table generation 
program 4533. The state transition table 4535 contains 
actions to be executed and the ID number of the next state 
to which the transition is to be made for each of combina- 
tions of the individual ArmCode instructions as inputted and 
the state ID numbers. In the pattern matching based on the 
state transition, a suitable one of action routines 4538 is 
selected for execution by reference to the state transition 
table in dependence on the ArmCode instruction as inputted 
and the current sate. A state slack 4544 serves for recording 
the state transition history. On the other hand, a register 
usage designation table 4546 contains records concerning 
the register usage designations intrinsic to the target 
machine, while a register correspondence table 4548 is used 
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for recording correspondence relations between the abstract 
registers in the program being processed and the physical 
registers. 

[0373] FIG. 31 is a view showing types of the physical 
registers in a machine B which differs from the machine A 
in respect to the instruction scheme. As shown in this figure 
at 4600, 1st to 7th and 16th to 23rd physical registers of the 
machine B can be used for the arithmetic operations as 
represented by "RcAriuY'. Similarly, there are represented 
by "RcAddr" at 4602 the physical register which can be used 
for the address calculation, while "RcTernp" at 4614 repre- 
sents the physical register used temporally. In this manner, 
there are indicated in FIG. 31 the usages of the physical 
registers in the machine B which differ from those of the 
machine A shown in FIG. 23. 

[0374] FIG. 32 is a view showing a part of correspon- 
dence relations between the physical registers incorporated 
in the machine B and the abstract registers. Although the 
abstract registers 4620 may be used in an arbitrary number 
as in the case of the machine A, the number of the physical 
register of the machine B is limited up to thirty-two. The 
abstract registers 4624 for placing function values therein 
are represented by "FuncvalO" and "Funcvall" and corre- 
spondences are established to the physical register "8" and 
"9", respectively, as indicated by 4631 and 4632. Repre- 
senting the abstract registers 4625 used for placing param- 
eters therein by "ParamO", "Paraml", . . . , "Pramp", there 
are established correspondence relations between these 
abstract registers and the physical registers "24" to "29" as 
indicated by 4633 and 4634. The abstract registers 4626 
used for arithmetic operation and represented by "RrO", 
"Arl", . . . , "Arq" bear correspondence relations to the 
physical registers "1" to "T and "16" to "23", as indicated 
by 4635, 4636, 3637 and 4638, respectively. Similarly, the 
abstract registers 4627 used for the address calculation and 
represented by "AddrO", "Addrl", . . . , "Addrr", respec- 
tively, bear correspondence relations to the physical regis- 
ters "1" to "7" and "16" to "23", as indicated by 4639, 4640, 
4641 and 4642, respectively. 

[0375] FIG. 33 is a view showing a part of the machine 
instruction generating rules oriented for the machine B. By 
way of example, the rule 4700 dictates how to generate the 
machine instruction in correspondence to the ArmCode 
instruction for the constant loading. The rule 4712 is for the 
machine instruction concerning the loading from a memory. 
The rule 4716 indicates how to generate machine instruc- 
tions for the ArmCode instruction sequence which dictates 
that the result obtained from the addition of registers Regl 
and Reg2 be placed in the register Reg3. In this way, FIG. 
32 shows the machine instruction generating rules which are 
required for translating the abstract object program shown in 
FIGS. 20 and 21 into a machine language program. FIG. 34 
is a view showing the correspondence relations of the 
physical registers incorporated in the machine B to the 
abstract registers in the program shown in FIGS. 20 and 21, 
as exemplified at 4780. More specifically, there are shown in 
this figure the results of the register allocation by the 
generation control instructions such as "alloc" , "free", etc. 

[0376] FIG. 35 is a view showing examples of the 
machine instructions generated by applying the rules shown 
in FIG. 33 to the ArmCode instructions shown in FIGS, 20 
and 21. More specifically, referring to FIG. 35, a machine 



instruction 4800 is generated by applying the rule 4700 
shown in FIG. 33 to the ArmCode instruction 4030 shown 
in FIG. 20, and a machine instruction 4802 is generated by 
applying the rule 4722 to the ArmCode instruction 4032. In 
this manner, the installer for the machine B applies the rules 
shown in FIGS. 20 and 21 to thereby generate the machine 
language program for the machine B as shown in FIG. 35. 

[0377] As will now be understood from the above descrip- 
tion, the installer for the machine A generates the machine 
language program for the machine A with the installer for the 
machine B generating the machine language program for the 
machine B, both from one and the same abstract object 
program. These two installers differ from each other with 
regard to the applicable machine instruction generating rules 
and the physical register usage designations. However, both 
installers are same in respect to the contents of the process- 
ing illustrated in FIG. 29. 

[0378] As will be appreciated from the foregoing, accord- 
ing to the instant embodiment of the invention, a major 
proportion of the global optimalization processing and the 
register allocation optimalization processing are carried out 
by the compiler which is independent of the target machines, 
wherein the information concerning the flow analysis, reg- 
ister allocation and others generated by the compiler is 
transferred to the installer, as a result of which the installer 
can generate the machine language program of improved 
execution performance or efficiency without need for com- 
plicated processing. Accordingly, even when the target- 
oriented machine language program is generated from the 
machine-independent abstract object program by the install- 
ers) every time the program is activated, there arises 
substantially no problem concerning the execution perfor- 
mance and the processing time taken by the installer. 

[0379] Further, according to the instant embodiment, soft- 
ware can be delivered to a plurality of different target 
machines in the form of the same abstract object program 
without involving necessity of adjusting the software or 
re-compilation for each of the target machines, whereby 
maintenance and management can significantly be facili- 
tated. 

[0380] Moreover, it is noted that according to the instant 
embodiment of the invention, the abstract object program is 
decomposed to very fine levels of manipulation when com- 
pared with the source program. Besides, the abstract object 
program differs from the source program with regard to the 
structure as well as sequence of the descriptions. For these 
reasons, it is practically impossible to restore the source 
program from the abstract object program. Thus, by deliv- 
ering a software in the form of the abstract object program 
to the users, it is possible for the user to execute one and the 
same program by a plurality of computers or machines 
and/or change the types of machines as used while main- 
taining in secrecy the software implementation schemes and 
algorithms contained in the source program. 

[0381] It should further be noted that by using the installer 
according to the present invention, one and the same source - 
level debug system can be made use of by a plurality of 
machines. An embodiment directed to this feature of the 
invention will be described below by referring to FIGS. 36 
to 45. 

[0382] FIG. 36 is a block diagram showing a structure of 
a debug system to which the installer according to the 
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invention is applied. Referring to the figure, a debugger 
5100 is used for degugging an abstract object program 5102 
generated by compiling a source program 5101. An installer 
5103 implemented according to the teachings of the inven- 
tion is used for translating the abstract object program into 
a machine language program 5107. Amain memory 5104 is 
employed for storing the machine language program 5107 
and a debug information table 5108. A display unit 5105 
serves for displaying the results to the user while an input 
device 5106 is used for receiving the inputs from the user. 

[0383] FIG. 37 is a flow chart for illustrating operation of 
the debugger. At first, an abstract object program 5102 is 
read (step 5120). Since the abstract object program contains 
source information indicating positions on the source pro- 
gram and others, a source-abstract object correspondence 
table is generated on the basis of the source information 
(step 5121). Subsequently, the installer is operated on the 
abstract object program as inputted, to thereby generate a 
machine language program on the main memory lstep 
5122). In that case, an abstract object-machine language 
correspondence table is generated for establishing corre- 
spondence between the abstract object program and the 
machine language program (step 5123). In this conjunction, 
it is to be noted that in the case of the instant embodiment, 
the source-abstract object correspondence table and the 
abstract object-machine language correspondence table are 
integrated into a single table (referred to as a source -abstract 
object -machine language correspondence table). This table 
is included in the debug information table 5108. When the 
user inputs a command requisite for the debugging (step 
5124), the processing flow is branched in dependence on the 
type of the inputted command (step 5125). More specifi- 
cally, when a display command is inputted, a displaying 
processing is executed (step 5126), ;F6r a break point setting 
"command as inputted/ a break point setting processing is 
executed (step 5127), while for an execution command, 
^execution processing is performed (step 5128). Upon 
completion of these processings, the flow is repeated, start- 
ing from the step 5125. The command processings men- 
tioned above will be described in more detail by reference to 
FIGS. 38 to 43. When the input command is an exit 
command, the processing is terminated. 

[0384] FIG. 38 is a view showing an example of the 
display command. In the case of this example, the display 
command is for the value of the variable i. The display 
command, includes a command name PRT 5131 to be 
displayed and a variable name i 5132. 

[0385] FIG. 39 is a flow chart for illustrating the display 
processing in detail. In other words, this figure shows details 
of the processing step 5126 shown in FIG. 37. Referring to 
FIG. 39, the variable name in the display command is 
extracted (step 5133). Subsequently, by consulting the 
source-abstract object-machine language correspondence 
table (hereinafter referred to simply as correspondence 
table), the variable name is translated into an address on the 
main memory on which the content of that variable is stored, 
which is then followed by a step 5135 where the content of 
the address determined at the step 5134 is read out from the 
main memory (step 5135). Then the content as read out 
undergoes translation in accordance with data type of the 
variable read out to be thereby displayed on the display 
device. 



[0386] FIG. 40 is a view showing an example of the 
break-point setting command: More specifically, this exem- 
plary command is for setting a break point in the statement 
numbered "10" in the source program and composed of a 
command name (identifier or ID) 5141 and a statement ID 
number 5142. 

[0387] FIG. 41 is a flow chart for illustrating a break-point 
setting processing and shows details of the processing in the 
step 5127 shown in FIG, 37. Referring to FIG. 41, the 
statement ID number in the command is extracted (step 
5143). Thereafter, a flag is set which indicates that the brealr 
point has been set at the corresponding statement ID number 
in the correspondence table (step 5144). 

[0388] FIG. 42 is a view showing an example of execution 
command, which commands execution of program and 
consists only of a command name 5151. 

[0389] FIG. 43 is a flow chart for illustrating execution 
processing and shows details of the processing in the step 
5128 shown in FIG. 37. Referring to FIG. 43, only one 
instruction is first executed (step 5152). This can be realized 
by running a CPU in such a mode that trap is validated every 
time one instruction has been executed, at this time, the 
control is transferred back to the debugger. Subsequently, 
address of the instruction is extracted (step 5153), which can 
be - realized, for example, by reading out the content of a 
program counter. Finally, in a step 5154, if is checked by 
consulting the correspondence table whether the breakpoint 
is set at the extracted address. Unless the break point is set, 
the processing is repeated, starting from the step 5152, while 
the processing comes to an end when the break point is set. 

[0390] FIG. 44 is a view showing an example of the 
source program which is subject to the debugging. In this 
figure, the statement numbers 5160 and descriptions 5161 of 
the statements in the source program are shown. It should 
however be mentioned that the statement number is not 
contained in the actual source program. The following 
description of the instant embodiment will be made on the 
assumption that the source program shown in FIG. 44 is 
used. 

[0391] FIG. 45 is a view showing an example of a 
source-abstract object-machine language correspondence 
table. This correspondence table is composed of (a) a 
statement information table and (b) a variable information 
table. The statement table includes four fields which corre- 
spond to the source program statement number 5170, the 
abstract object program instruction address 5171, the 
■machine language program instruction address 5172 and the 
break-point set flag 5173, respectively. Referring to FIG. 
45A, an entry 5174, for example, indicates that the statement 
numbered "10" is an instruction located at the address of 
"000060" in the abstract object program, while it is an 
instruction located at the address of "000040" in the 
machine language program and that a break point is set in 
this statement. 

[0392] The variable information table shown in FIG. 45B 
includes five fields for a variable name 5175, a variable type 
5176, a data type 5177, a line number 5178 and a machine 
address 5179, respectively. The variable names 5185 repre- 
sent names of variables in the source program. The variable 
types 5176 represent discriminatively local variables and 
global variables. The data type 5177 represents the data 
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types 5177 of the variables. The statement number 5178 
represents the position on the source program at which the 
variable has been declared. The machine language address 

5179 is the information of the address of the variable on the 
machine language program and represents an offset from a 
frame pointer in the case of the local variable while repre- 
senting an offset from a base address of the variable area in 
the case of the global variable. By way of example, an entry 

5180 indicates that the variable i is a local variable, the data 
type is "int" which is located in the statement numbered "4" 
of the source program and that the offset from the frame 
pointer on the machine language program is "-4". 

[0393] As will be understood from the above description, 
the debug system according to the illustrated embodiment of 
the invention can enjoy an advantageous effect that one and 
the same abstract object program can be debugged by plural 
types of systems because the installer is incorporated for 
translating the machine -independent abstract object program 
into an target machine language program. 

[0394] By utilizing the installer according to the invention, 
the abstract object program can be supplied in the form of IC 
card or CD-ROM or the like so as to provide a machine - 
independent offhand-executable system. For example, by 
incorporating a game program in an IC card while incorpo- 
rating the installers in individual machines, respectively, it is 
possible to execute one and the same game program by 
different machines (IC card systems). An exemplary 
embodiment of such system will be described below by 
reference to FIGS. 46 to 50. 

[0395] FIG. 46 is a block diagram showing a structure of 
an IC system incorporating an installer according to the 
invention. The IC card system shown in this figure includes 
a controller 5000, a main memory 5002, an IC card read/ 
write device 5005, a keyboard 5006 and a display 5007. The 
controller 5000 incorporates therein a CPU 5001. On the 
other hand, the main memory 5002 incorporates an installer 
5003. An IC card 5008 is coupled to the IC card system via 
the IC card read/write device 5005. The program stored in 
the IC card is loaded into the main storage as a machine 
language program 5004 through the medium of the installer 
5003. 

[0396] FIG. 47 is a pictorial view showing an outer 
appearance of the I C card system. A user can input data with 
the aid of the keyboard 5006, while response to the user is 
displayed on the display unit 5007. The IC card is inserted 
through an IC card insertion slot 5009. 

[0397] FIG. 48 is a top plane view of the IC card 5008. 
Data transactions between the IC card and the IC card 
read/write device are realized via contact points 5010. A 
storage device 5011 stores an abstract object program 5012 
to be executed and data 5013, 

[0398] FIG. 49 is a flow chart for illustrating execution of 
the abstract object program incorporated in the IC card. In 
the first place, the IC card 5008 is inserted into the IC card 
slot 5009 (step 5020) to read out the abstract object program 
and the data stored in the IC card (step 5021). In response 
to the inputting of the abstract object program read out from 
the IC card, the controller 5000 activates the installer 5003 
(step 5022). As a result, there is generated in the main 
memory the target machine language program 5004, which 
is then executed (step 5023). As a result of the execution, the 



resulting data is written in the IC card, if it is required, in a 
step 5024, and the IC card is returned (step 5025). At this 
time the transaction comes to an end. 

[0399] FIG. 50 is a block diagram showing a system in 
which one and the same abstract object program contained 
in an IC card is executed by a plurality of IC card apparatus 
having different CPUs, respectively, according to an 
embodiment of the invention. It is assumed, by way of 
example, that the illustrated system includes IC card appa- 
ratuses A and B which incorporate in the respective con- 
trollers a CPU-A 5038 and a CPU-B 5039 which have 
mutually different instruction schemes, respectively. When 
the abstract object program placed in the IC card 5008 is to 
be used in the IC card apparatus A, the abstract object 
program is translated into a machine language program A 
5036 described in the CPU-A-oriented machine language. 
On the other hand, when the abstract object program of the 
IC card 5008 is to be used in the IC card abstract object 
program the former is translated into a machine language 
program B 5037 described in a CPU-B-oriented machine 
language. 

[0400] Although it has been assumed in the above descrip- 
tion that the IC card is used as the medium for storing and 
carrying the abstract object program, it should be appreci- 
ated that the present invention can equally be applied to the 
systems in which CD-ROM, floppy disk or the like is used. 

[0401] FIG. 51 is a block diagram showing a system in 
which ArmCode programs are shared by computer systems 
of different types which are linked together through a 
network. 

[0402] Connected to a network medium 1101 are a file 
server 1102 and computer systems which are exemplified by 
a computer system A 1103 and a computer system B 1104. 
A disk device 1105 is connected to the file server 1102 which 
serves for supplying file data from the disk device 1105 to 
the computer systems A and B (1103 and 1104). Each of the 
computer systems A and B can make access to the files on 
the disk device 1105 with the aid of their own remote file 
management programs (1106, 1107), Further, the computer 
systems A and B incorporate respective instructions (1108, 
1109) for translating the ArmCode program into machine 
language programs oriented to these computer systems, 
respectively. 

[0403] When an ArmCode program 1110 on the disk 
device 1105 is to be executed by the computer system A, the 
ArmCode program 1110 made available through the asso- 
ciated remote file management program 1106 is translated 
into a machine language program 1111 by the installer 1108 
to be subsequently executed by the computer system A. 
Similarly, a machine language program 1112 is generated for 
execution by the computer system B as well. 

[0404] In this manner, one and the same ArmCode pro- 
gram can be executed by a plurality of computers of different 
types connected to the network, which means that common- 
ability of the object program is realized. 

[0405] In the prior art system, it was impossible to make 
an object program commonable to the machines of different 
types, making it necessary for each machine to hold an 
object program having a same function. In contrast, by 
consolidating the object program files required for every 
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types of the machine for a certain function in an ArmCode 
program file as described above, there can be assured 
advantages mentioned below. 

[0406] (1) File capacity of a whole network system can be 
reduced. 

[0407] (2) The bug correction and extension of function 
may be performed only for the ArmCode program without 
necessitating simultaneous execution for a plurality of object 
programs, whereby time and labor for version management 
of the object programs can remarkably be reduced. 

[0408] FIG. 52 is a block diagram for explaining replace- 
ment of a computer system in which an ArmCode program 
is employed by another type of computer system. 

[0409] Referring to the figure, it is assumed that in a 
computer system A 1201, a machine language program 
running thereon is stored on an associated disk device 1202 
in the form of ArmCode program. In other words, when a 
certain function is to be implemented by the computer 
system A 1201, the ArmCode program 1204 on the disk 
system 1202 which corresponds to the function is translated 
into a machine language program 1205 oriented for the 
system A 1201 by an installer 1203 for execution. 

[0410] This type of computer system can easily be 
replaced by another computer system which incorporates an 
installer. Namely, replacement of the computer system A 
1201 by another system B 1206 can readily be accomplished 
only by copying the ArmCode program 1204 on the disk 
device 1202 onto a disk device 1207. Thus, when a certain 
function implemented by the computer system A 1201 is to 
be implemented by the computer system B 1206, the Arm- 
Code program corresponding to that function and copied 
onto the disk device 1207 is translated into a machine 
language program 1209 by the installer 1208 to be subse- 
quently executed. 

[0411] By adopting the ArmCode as a scheme for reserv- 
ing programs on the disk, advantages mentioned below can 
be obtained. 

[0412] (1) For the user, the time and labor involved in 
exchange or switching of the computer systems such as 
recompiling of source program and regeneration of machine 
language programs can considerably be reduced. 

[0413] (2) For the manufactures, a system design for 
maximizing computer performances can be facilitated 
because of capability of generating the machine language 
without need for taking into account the exchangeability or 
switchability of the computer system. 

[0414] As will now be appreciated from the foregoing 
description, it is possible according to the teachings of the 
present invention to generate a machine language instruction 
sequence by effectively making use of the real machine 
registers by virtue of optimalization of abstract register 
usage by the compiler and the real register allocating func- 
tion of the installer. Moreover, owing to the instruction 
language pattern replace function of the installer, high-level 
functional instructions of the real machine can effectively be 
utilized. 

1. An information processing system, comprising: 

a compiler for translating source programs into abstract 
object programs; 



a linker for linking together said abstract object programs 
to generate a linked abstract object program; and 

a plurality of installers provided for different types of 
machines, for translating said linked abstract object 
program into machine language programs respectively. 

2. An information processing system according to claim 1, 
wherein said abstract object program is composed of a 
sequence of instructions for an abstract register machine, 

wherein said abstract register machine including a plu- 
rality of registers and executing transfer instructions 
between said registers and a memory, computational 
instructions on the registers and branch instructions for 
controlling a sequence of executions of said instruc- 
tions, and 

wherein said installers being provided in a number cor- 
responding to a number of different instruction set 
computers in which instruction specifications differ 
from one another, wherein one and the same abstract 
object program resulting from the translation of said 
source program by said compiler is translated into said 
machine language programs oriented to said different 
machine types of the computers, respectively, by means 
of said installers provided in association with said 
computers, respectively, for thereby allowing machine 
language program to be executed by the target com- 
puter to which said machine language is oriented. 

3. An information processing system according to claim 2, 
wherein said abstract object program includes, in addition to 
machine language corresponding instructions representing 
machine instructions for the target computers, at least one of 
instructions selected from a group consisting of a generation 
control instruction for controlling generation of a machine 
instruction sequence a pseudo-instruction representing a 
structure of a program, a pseudo-instruction for establishing 
correspondences between instructions in the program and 
symbol names, a pseudo-instruction for establishing corre- 
spondences between locations or sizes of the memory used 
by the program and symbol names and a pseudo-instruction 
indicating debugging information. 

4. An information processing system according to claim 3, 
wherein said abstract object program includes indication for 
selecting the positions for generation of machine instruction 
sequence of the computer indicated by said machine instruc- 
tion sequence corresponding instruction in conformance 
with register allocation state in which said registers are 
allocated. 

5. An information processing system according to claim 2, 
wherein said abstract object program includes at least one of 
an indication for allocation of said registers and an indica- 
tion for freeing said registers. 

6. An information processing system according to claim 2, 
wherein said abstract object program includes at least one of 
an indications concerning types of said registers, priorities 
of the registers in the allocation of said registers and a 
number of the registers to be preserved. 

7. An information processing system according to claim 6, 
wherein said register allocation priority is determined in 
dependence on the use frequency of the abstract register or 
use position thereof. 

8. An information processing system according to claim 2, 
wherein said compiler has a function for performing con- 
version of the instruction sequence, deletion of instruction, 
modification of instruction or move of instruction for 
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thereby evading duplicative execution of the instruction in 
said abstract register machine instruction sequence. 

9. An information processing system according to claim 2, 
wherein said installer has a function for allocating physical 
registers of said computer to the registers in said abstract 
object program in conformance with indication of a memory 
designation pseu do -instruction included in said abstract 
object program upon generation of said machine language 
program of said computer from said abstract object program. 

10. An information processing system according to claim 
2, wherein said installer has a function for selectively 
determining whether allocation of physical registers of said 
computer to the registers of said abstract register machine is 
to be executed offhand or not or for messaging whether said 
physical registers could be allocated or not. 

11. An information processing system according to claim 
2, wherein said installer has a function for recording priori- 
ties of physical registers of said computer in allocating said 
physical registers to the registers of said abstract register 
machine even after allocation command has been issued. 

12. An information processing system according to claim 
2, wherein said installer has a function capable of changing 
priorities of physical registers of said computer upon allo- 
cating said physical register to abstract registers constituting 
said registers of the abstract register machine, even after said 
allocation priorities have been specified, in conformance 
with position of said abstract register machine instruction 
being executed or position of said abstract register instruc- 
tion using said abstract register. 

13. An information processing system according to claim 
2, wherein said installer has a function of generating the 
machine language program in a form in which a machine 
language instruction sequence is changed in conformance 
with structures of preceding and succeeding instruction 
sequences, regardless of a form of the abstract register 
machine instruction sequence which corresponds to said 
machine language instruction sequence. 

14. An information processing system according to claim 
13, wherein said installer has a function of generating the 
machine language program in a form in which a machine 
language instruction sequence is changed in conformance 
with situation in which physical registers of the computer 
are allocated regardless of a form of the abstract register 
machine instruction corresponding to said machine language 
instruction sequence. 

15. An information processing system according to claim 
13, wherein said installer has a function for optimalizing the 
machine language program in conformance to characteris- 
tics of the computer. 

16. An information processing system according to claim 
2, wherein said installer generates the machine language 
program from the abstract object program in accordance 
with machine language instruction generating rules estab- 
lished for said abstract register machine instruction 
sequence. 

17. An information processing system according to claim 
15, wherein said installer has a function capable of gener- 
ating from one and the same abstract object program dif- 
ferent machine language programs conforming to the target 
computers by changing the machine language instruction 
generating rules for said abstract register machine instruc- 
tion sequence in conformance to the target computers. 



18. An information processing system, comprising; 

a compiler for translating a source program into object 
programs; and 

a target computer for executing computational operations 
in accordance with instructions of said object pro- 
grams; 

wherein each of said object programs includes in 
addition to executable instructions sequence for said 
target computer at least one of instructions selected 
from a group consisting of a generation control 
instruction for controlling allocation or release of 
registers, a pseudo-instruction representing a struc- 
ture of the source program, pseudo-instructions for 
establishing positions of instructions in the program 
and symbol names, pseudo-instructions for estab- 
lishing correspondences between locations or sizes 
of memory used by the program and symbol names 
and pseudo-instructions and a pseudo-instruction for 
indicating debugging information. 

19. A machine language program generating system, 
comprising: 

a compiler for translating source programs into abstract 
object programs each including an abstract register 
machine instruction sequence; 

a linker for linking together a plurality of said abstract 
object programs to thereby generated a linked abstract 
object program; and 

an installer for translating a given one of said abstract 
object programs into a machine language program 
which is stored in a memory of a computer; 

wherein said installer is provided for each of the 
computers having instruction schemes differing from 
one another, to thereby allow a processing operation 
indicated by one and the same abstract object pro- 
gram to be executed by each of said plural computers 
in different instruction set. 

20. A debug system loaded with a source program 
described in a high-level language and an abstract object 
program generated by translating said source program, 
wherein said abstract object program has a plurality of 
abstract registers and is composed of an abstract register 
machine instruction sequence which includes a transfer 
instruction between said register and a memory, a compu- 
tational instruction executed on said registers and a control 
instruction for controlling the sequence of instructions, 

said debug system further comprising means for translat- 
ing said abstract object program into an executable 
machine language program. 

21. A debug system according to claim 19, wherein one 
and the same abstract object program is executed by a 
plurality of different machine types of computers. 

22. A debug system according to claim 19, wherein one 
and the same debug system is implemented by a plurality of 
different machine types of computers. 

23. An information processing system, comprising: 

a portable storage medium; and 

an information processor for performing data transactions 
with said portable storage medium loaded in said 
information processor; 
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wherein said portable storing medium stores therein an 
abstract object program which includes a plurality of 
abstract registers and is composed of an abstract 
register machine instruction sequence including a 
transfer instruction between said register and a 
memory, computational instructions for said regis- 
ters and an instruction for controlling the sequence of 
said computational instructions, 

said information processing system further including 
means for reading and translating said abstract object 
program into an executable machine language pro- 
gram. 

24. An information processing system according to claim 
22, wherein said portable storage medium is constituted by 
an IC card. 

25. An information processing system according to claim 
22, wherein said portable storage medium is constituted by 
a CD-ROM. 

26. A network computer system in which a plurality of 
different instruction set of computers are connected to a 
network; 

wherein at least one of said computers connected to said 
network functions as a server equipped with the 
abstract object program set forth in claim 2; 

each of the other computers connected to said network 
including means for accessing said abstract object 
program of said server and the installer set forth in 
claim 2; and 



each of said other computers connected to said network 
translating said abstract object program supplied from 
said server into respective machine language programs 
for execution thereof by means of said installer pro- 
vided in association with each of said other computers. 

27. A computer system replacing method, comprising 
steps of: 

replacing a computer system incorporating the abstract 
object program and the installer set forth in claim 2 by 
another computer system equipped with the installer set 
forth in claim 2; and 

executing the abstract object program before said replace- 
ment by the computer system after said replacement. 

28. A method of generating from at least one source 
program a machine language program suitable for a type of 
computer, the method being executed by a computer system 
and comprising the steps of: 

compiling said at least one source program to generate an 
abstract object program for an abstract machine; and 

translating said abstract object program into a machine 
language program in accordance with a type of com- 
puter, the machine language program being executed 
by the computer. 

* * * * * 
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